Migrazione da .NET Framework a .NET 8: un’esperienza in sanità

Migrare un applicativo da .NET Framework a .NET 8 non vuol dire ricompilarlo: le pagine Web Forms vanno riscritte su ASP.NET Core, e i difetti si chiudono solo correggendo autenticazione, query, gestione dei segreti, autorizzazioni e test. L’abbiamo verificato nella migrazione .NET Framework a .NET 8 di un applicativo gestionale di un’azienda ospedaliera, di proprietà dell’ente, che supporta l’organizzazione dei servizi interni. Ecco cosa abbiamo imparato.

Migrazione .NET Framework a .NET 8: il runtime da solo non basta

Molte aziende sanitarie usano ancora applicativi web nati dieci o quindici anni fa su ASP.NET Web Forms e .NET Framework. Funzionano, ma ogni anno sono più difficili da mantenere e da proteggere. La prima lezione è la più importante: cambiare runtime non corregge il prodotto. Ricompilare lo stesso codice su .NET 8 porta con sé gli stessi difetti. Per questo il lavoro è partito da un’analisi scritta delle criticità, ordinate per effetto sul servizio, e solo dopo dal codice.

Le criticità tipiche di un Web Forms datato

Sono problemi che ritroviamo in quasi tutti gli applicativi di quella generazione, non solo in sanità:

• Query costruite concatenando i valori inseriti dall’utente: un apice nel dato cambia il testo della query inviata al database;
• Autorizzazione affidata al menu: nascondere una voce non impedisce di aprire l’indirizzo della pagina, se il divieto per gli utenti anonimi non è centralizzato;
• Credenziali in chiaro nel file di configurazione, spesso con un account amministratore del database, quindi presenti in ogni copia del progetto e del pacchetto di rilascio;
• Componenti fermi: librerie di interfaccia commerciali non più aggiornate, modelli dati non versionati, provider di database deprecati, nessun test automatico;
• Stato in memoria: dati di sessione che si perdono al riavvio del server, mentre l’utente risulta ancora autenticato;
• Integrazioni in HTTP senza cifratura e programmi satellite su versioni diverse del framework per lo stesso flusso.

Come si affrontano su ASP.NET Core

• Query parametrizzate ovunque, e filtri LDAP con l’escape previsto dallo standard;
• Ruoli e permessi nel database, trasformati in claim al login: ogni controller dichiara la policy che richiede, il menu legge gli stessi claim, chi non ha il permesso riceve un accesso negato;
• Cookie di sessione protetti (HttpOnly, Secure, SameSite Strict), token antiforgery sui POST, HSTS e intestazioni di sicurezza fuori dall’ambiente di sviluppo;
• Segreti fuori dal repository: il pacchetto di rilascio non contiene credenziali, che restano sul server o in un secret store, con un account applicativo dai soli diritti necessari;
• Migrazioni EF Core al posto del modello generato, così lo schema è versionato insieme al codice;
• Job pianificati e notifiche in tempo reale nello stesso processo: le acquisizioni periodiche non dipendono più da programmi esterni, e le schermate aperte vengono avvisate delle modifiche;
• Registro delle attività con utente, orario e indirizzo IP, e una suite di test sui flussi operativi.

Tre lezioni che valgono per ogni migrazione

Scrivere prima la tabella delle criticità

Per ogni problema: com’è oggi, che effetto ha sul servizio, come si tratta nella versione nuova e con quale esito. È il documento che permette all’ente di decidere e al fornitore di non dimenticare nulla.

Dire cosa resta aperto

Alcune criticità si chiudono nel codice ma possono tornare in fase di installazione: se in produzione si ricopia una stringa di connessione con un utente amministratore, il privilegio eccessivo resta. Scriverlo evita sorprese.

Portare le API nello stesso host

Un sito e un servizio API separati sugli stessi dati significano due autenticazioni e due punti da mantenere. Riunirli semplifica sia la sicurezza sia l’esercizio.

Un percorso che conosciamo anche dall’interno

Il nostro software storico Recupero.Net è su .NET Framework, mentre il nuovo gestionale RecuperoNext è stato scritto da zero su ASP.NET Core. Se hai un applicativo su .NET Framework che nessuno vuole più toccare, possiamo partire da un’analisi delle criticità, anche solo documentale: è il primo passo del nostro audit di sicurezza, e la riscrittura rientra nello sviluppo software aziendale e nella system integration.

Domande frequenti

Si può portare un’applicazione Web Forms su .NET 8?

Non direttamente: Web Forms non esiste in ASP.NET Core. Le pagine vanno riscritte, per esempio in MVC con Razor, riusando dove possibile regole e query dopo averle rese sicure.

La migrazione a .NET 8 rende automaticamente sicuro l’applicativo?

No. Il nuovo runtime offre strumenti migliori, ma query concatenate, credenziali in chiaro e autorizzazioni deboli vanno corrette esplicitamente nel codice e nella configurazione di rilascio.

Serve fermare il servizio per migrare?

In genere no: la nuova versione si sviluppa e si collauda in parallelo, sugli stessi dati o su una copia, e si passa in produzione quando i flussi principali sono coperti dai test.

L’applicativo descritto è di proprietà dell’azienda sanitaria. Per riservatezza sono omessi il nome dell’ente, dei sistemi collegati e ogni dettaglio infrastrutturale.