PITRE riuso: La sicurezza parte dall'architettura di rete

mario_servino · 11 Gennaio 2023, 11:06am

Con questo primo post vorrei condividere “in riuso” con responsabili tecnici ed organizzativi nell’ambito della gestione documentale e protocollo informatico una serie di issues riguardanti l’applicazione PITRE anche nella versione più datata DOCSPA. I temi trattati sono: security, performance tuning, monitoring, deploy, help desk e altre issues evidenziate da tutti quelli che vogliono mettere “a riuso” le proprie esperienze a beneficio della Pubblica Amministrazione Italiana

PITRE è stata un’iniziativa importante da parte della PA, ma alcuni aspetti come la sicurezza non sono stati aggiornati nel tempo secondo una metodologia “a riuso”.

Da alcuni anni la PA ha richiesto che il codice PITRE venga sottoposto ad assesment di sicurezza, su ogni versione in riuso e personalizzata sono state apportate una serie di aggiornamenti del codice che assicurano un adeguato livello di robustezza che lo rendono resistente a qualsiasi, o quasi, attacco informatico.
Questo tipo di intervento si colloca nella parte down della sicurezza informatica, cerchiamo di analizzare la security con un approccio top to down partendo dall’infrastruttura dei sistemi e della rete a supporto dell’applicazione PITRE.

L’architettura qui descritta si basa sull’infrastruttura di sistemi Microsoft Windows Server, sia in modalità Active Directory che Workgroup (standalone). Non viene trattata la sicurezza della rete, ma si consiglia di abilitare solo i protocolli di rete necessari e solo tra nodi ben identificati.

Data Base
Per garantire l’alta affidabilità il data base è gestito da Microsoft SQL Server in modalità AlwaysOn che prevede l’utilizzo di 2 servers che allineano i dati in tempo reale. L’accesso ai data base è consentito solo ad un utente di servizio (Managed Service Account MSA), utente utilizzato dal BackEnd PITRE (Identity). Questa modalità prevede di utilizzare una stringa di connessione “sicura” in cui non compare utente e password “userid=docsadm; password=password” ma solo la chiave “Trusted_Connection=True”.

Nota: se si sceglie di non utilizzare un dominio Active Directory, i servers sono configurati in modalità Workgroup e non è possibile utilizzare un MSA. In questo caso bisogna creare un utente di servizio su ogni server mantenendo stessa userid e password. Ovviamente la password non deve scadere mai e deve essere gestita secondo criteri di sicurezza adeguati.

File Server
Anche qui l’alta affidabilità è garantita da un cluster con 2 nodi e da uno ò più dischi. L’accesso al disco condiviso è consentito solo ad un utente di servizio (Managed Service Account MSA), utente utilizzato dal BackEnd PITRE (Identity).

Servizi PITRE
I servizi e tasks PITRE sono di norma installati su un server di BackEnd ma questa soluzione non garantisce l’alta affidabilità (se il server va in errore i servizi non vengono eseguiti), mentre un cluster dedicato garantisce che i servizi e task vengano sempre eseguiti.

Nota: nel caso in cui si utilizza solo il protocollo HTTPS alcuni servizi e tasks PITRE che utilizzano i servizi SOAP/REST di BackEnd devono essere aggiornati.

Nota: Alcuni servizi e tasks che accedono ai web services di BackEnd necessitano di parametri di accesso a PITRE tra cui utente e password con determinati diritti di accesso ai documenti. Questi parametri sono contenuti in chiaro in un file di configurazione .config violando una fondamentale regola di sicurezza. Per ovviare a questo problema si può cifrare il file di configurazione tramite procedura che verrà descritta in apposita issue.

PITRE BackEnd
I web services del BackEnd PITRE sono installati su servers dedicati che comunicano tramite una sottorete dedicata. Il traffico verso i servers di BackEnd è gestito da un bilanciatore configurato in modalità sticky session che garantisca il mantenimento della sessione tra frontend/altri sistemi e server di BackEnd.
Nel caso di multi istanza il BackEnd può essere installato su batterie di servers dedicati attestati su sottoreti diverse.

PITRE FrontEnd
Le web application FrontEnd ed AdminTool di PITRE sono installati su servers dedicati che comunicano tramite una sottorete dedicata. Il traffico verso i servers di FrontEnd è gestito da un bilanciatore configurato in modalità sticky session che garantisca il mantenimento della sessione tra le work station e server di FrontEnd.

Accessso remoto (SmartWorking)
La modalità più comune per accedere a PITRE da remoto è quella di avviare una connessione VPN alla intranet.
Una seconda modalità è quella di utilizzare Azure Tenant AD authentication che consente al proprio account Microsoft AD di accedere a PITRE in modalità windows autentication (senza richiesta di credenziali PITRE).

Architettura PITRE

mario_servino · 11 Gennaio 2023, 11:13am

Creazione di un Managed Service Account gMSA

In questo post si descrive come creare un utente gestito, da utilizzare in quei casi dove è necessario gestire un’identità da associare ad un servizio Windows, ad esempio utente per accedere ad un data base di SQLServer o per accedere ad una cartella condivisa di un file server.
Questi 2 articoli spiegano come creare un gMSA:

Come utilizzare un gMSA con web service BackEnd PITRE

Selezionare Application Pool associato alla Web Application BackEnd PITRE e aprire pannello Impostazioni Avanzate
Selezionare Identità, Account Personalizzato ed inserire il nome del gMSA (la password non viene richiesta)

gMSA_IIS

Selezionare la Web Application BackEnd PITRE, Impostazioni Applicazione (contenute nel file web.config) e cambiare il parametro connectionString

“server=localhost\sqlexpress; database=PITRE; UserId=utente; Password=password; Pooling=true; Min Pool Size=30; Connection Timeout=1200; Max Pool Size=1000”

“server=localhost\sqlexpress; database=PITRE; Trusted_Connection=True; Pooling=true; Min Pool Size=30; Connection Timeout=1200; Max Pool Size=1000”

gMSA_IIS2

Come utilizzare un gMSA con Windows Service
Un servizio PITRE che deve accedere al data base PITRE o ai web services di BackEnd PITRE (solo se abilitata la Windows Authentication) può essere eseguito con account gMSA.
Aprire app Servizi, selezionare il servizio PITRE e Proprietà, pannello Connessione, opzione Account ed inserire il gMSA (la password non viene richiesta)

gMSA_IIS3

Come utilizzare un gMSA con Windows Task Schedulati
Un task PITRE che deve accedere al data base PITRE o ai web services di BackEnd PITRE (solo se abilitata la Windows Authentication) può essere eseguito con account gMSA.
Aprire app Task Scheduler, selezionare il task PITRE, nel pannello Generale selezionare tasto Cambia utente o gruppo ed inserire il gMSA (la password non viene richiesta)

Come utilizzare un gMSA con cartella condivisa su file server

Creare la cartella condivisa, nelle proprietà aprire il pannello Sicurezza ed inserire l’utente gMSA con controllo completo

gMSA_IIS4

mario_servino · 11 Gennaio 2023, 11:17am

Accedere ai log applicativi

La quasi totalità dei moduli PITRE, web application, servizi e tasks, utilizzano il modulo LOG4NET per la gestione dei log applicativi che servono sia per segnalare errori che per tracciare le operazioni che il modulo esegue.
Il caso più rappresentativo è il BackEnd di PITRE, chi ha lavorato “hands on” sul prodotto sa bene il livello di dettaglio delle operazioni eseguite dal modulo di BackEnd e di quanto queste informazioni aiutino a capire eventuali errori che si possono verificare.
LOG4NET consente diversi livelli di tracciatura dei log ed i livelli utilizzati sono:
ERROR traccia solo le chiamate al modulo eseguite a fronte di condizioni di errore
DEBUG traccia tutte le chiamate al modulo, sia di errore che di tracciatura

Sebbene la tracciatura in modalità ERROR sia la più logica da configurare, la complessità dell’applicazione, dovuta anche alle varie personalizzazioni, costringe all’utilizzo della modalità DEBUG che ha però il “difetto” di generare molte tracciature che saturano velocemente il file di log.
In un sistema PITRE con alcune centinaia di utenti collegati contemporaneamente, il BackEnd può saturare il file di log da 10Mb in pochi minuti e sebbene si possono configurare file di log a rotazione (normalmente sono gestiti 10 files di log) le informazioni importanti presenti in un file di log potrebero essere cancellate.

La soluzione ideale è quella di poter cambiare il livello di log dei Web Services del BackEnd da ERROR a DEBUG e viceversa in modo programmatico, cioè attraverso una chiamata ad un web service specifico esposto dall’applicazione. Cambiarlo da file di configurazione web.config comporta il riavvio dell’application pool associato al Web Service con conseguente chiusura di tutte le sessioni applicative aperte. Gli utenti rimangono “appesi” e devono ricollegarsi al sistema PITRE. A questo link c# - Change log4net logging level programmatically - Stack Overflow trovate il codice necessario per realizzare questo web service, modifica già inserita in alcune installazioni di PITRE in riuso.
Creare il nuovo web service ChangeLogLevel e pubblicare il nuovo BackEnd PITRE, per cambiare il livello di log del BackEnd PITRE utilizzare questa semplice procedura PowerShell

– Procedura per cambiare il livello di log di LOG4NET di una web application
– La URL è composta dal nome del server, nome della web application, modulo di interfaccia WSDL
$svc = New-WebServiceProxy –Uri ‘https://server/PITRE-BE/Docspaws.asmx?WSDL’
$LogLevel = Read-Host "Inserire livello log (ERROR,DEBUG) "
$svc.ChangeLogLevel($LogLevel)

Altra problematica non meno importante si presenta su installazioni di BackEnd e FrontEnd su batterie di server bilanciati, quando viene segnalato un errore da un utente non è possibile capire su quale server è stato loggato e bisogna esaminarli tutti!
Per ovviare a questo problema ho realizzato una procedura PowerShell di facile gestione da avviare sui servers di BackEnd, FronEnd e servizi/tasks. La procedura esamina in tempo reale i files di log ed a seguito della scrittura di un log di errore esegue:

estrae un numero configurabile di linee di testo precedenti alla segnalazione di errore
Invia il testo come allegato ad un indirizzo email configurabile corrispondente all’help desk
L’help desk rileva dalla email il server da cui proviene la segnalazione ed eventualmente vi accede per ulteriori verifiche.
Se la verifica certifica la presenza di un errore viene aperta una segnalazione di BUG al gruppo di sviluppo allegando il testo rilevato dal log.
Se l’errore non viene identificato si procede tramite web service al cambio del livello di log da ERROR a DEBUG e si attende che l’errore si riverifichi.

La procedura è disponibile gratuitamente su richiesta

mario_servino · 13 Gennaio 2023, 9:41am

Log4net incide sulle prestazioni PITRE?

Come detto in precedenza l’utilizzo del livello di log ERROR non influisce sulle prestazioni del BackEnd PITRE perché il log viene scritto nel file solo in caso di errore, mentre il livello di log DEBUG può influire a causa dell’alto numero di log scritti nel file, scritture sincrone che possono rallentare l’esecuzione del processo IIS che gestisce la web application di BackEnd PITRE.
In questo post Using asynchronous log4net appenders for high performance logging si trovano interessanti spunti su come utilizzare Log4Net in modalità asincrona. L’autore segnala che in modalità sincrona le performances dell’applicazione non subiscono particolari rallentamenti, ma nel caso specifico il processo IIS di BackEnd PITRE è fortemente sollecitato sia dalla scrittura dei log che dalla scrittura su cartelle temporanee di files di servizio.
L’autore segnala anche che utilizzando la scrittura asincrona si potrebbe perdere la sequenzialità temporale dei log, ma nel caso PITRE viene anche loggata la data-ora-millisencondi che verrebbero in aiuto nel caso di consultazione.

mario_servino · 16 Gennaio 2023, 1:28pm

Cifratura file di configurazione .config

I files di configurazione PITRE (web application, servizi, task) contengono i parametri che determinano il comportamento della relativa applicazione. La loro integrità è fondamentale a garanzia del corretto funzionamento e della sicurezza.

Come proteggersi da eventuali manipolazioni non autorizzate di questi files?

Semplice, Microsoft ha realizzato un meccanismo di cifratura basato su chiave dei files .config che, una volta applicato, non richiede la modifica delle applicazioni per implementare la decifratura che in sostanza si colloca nell’interfaccia standard di accecsso ai parametri di configurazione.

Per prima cosa bisogna inserire nei files di configurazione .config una nuova sezione

……

<add name=“PITREProvider”

type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration, Version=2.0.0.0,

Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

keyContainerName="PITRE

useMachineContainer=“true” />

……

Avviare CMD.EXE ed eseguire:

Creare la chiave di cifratura

C:\windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pc "PITRE” -exp

Esportare la chiave e custodirla in un luogo sicuro

C:\windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -px “PITRE” "c:\PITRE\PITRE-RSAKey.xml -pri

Abilitare l’utente di servizio PITRE all’utilizzo della chiave

C:\windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pa “PITRE” PITRE_Utente_Servizio -full

Abilitare application pool IIS all’utilizzo della chiave (esempio app pool del BackEnd)

C:\windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pa “PITRE" “IIS AppPool\PITRE-BE" -full’

Cifrare e decifrare web.config del BackEnd PITRE

C:\windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pe “appSettings” -app “/PITRE-BE” -prov “PITRE”

C:\windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pd “appSettings” -app “/PITRE-BE” -prov “PITRE”

Cifrare e decifrare .config dei servizi PITRE

C:\PITRE\ExcryptExeConfigPiTre.ps1 -sectionName “appSettings” -exePath C:\PITRE\Services\PITRE_StampaRegistri\StampaRegistri.exe -encrypt

C:\PITRE\ExcryptExeConfigPiTre.ps1 -sectionName “appSettings” -exePath C:\PITRE\Services\PITRE_StampaRegistri\StampaRegistri.exe -decrypt

Esempio di web.config cifrato del BackEnd PITRE

Su richiesta è disponibile una procedura PowerShell con interfaccia interattiva che consente di eseguire tutte le operazioni sopra descritte ed altro ancora.

mario_servino · 18 Gennaio 2023, 5:37pm

Visibilità e sicurezza dei documenti

PITRE garantisce la privacy dei documenti tramite il concetto di visibilità, solo gli utenti autorizzati possono accedere ai documenti: il proprietario, gli utenti appartenenti allo stesso ruolo del proprietario e gli utenti ed i ruoli a cui il documento è stato trasmesso.
Tramite applicazione PITRE il documento è protetto da accessi non autorizzati ma se scendiamo a livello di infrastruttura il file su file server che lo contiene è accessibile al personale tecnico che gestisce l’infrastruttura e che potrebbe divulgarne i contenuti (vedi casi WikiLeaks e CIA/Snowden).
Come proteggersi da questo tipo di violazione della privacy dei documenti? La cifratura dei files che li contengono.
Tecnicamente la cifratura è un’operazione semplice da configurare, vedi Encrypted File System EFS di Microsoft Windows File Server, ma richiede una gestione organizzativa ben definita per la corretta conservazione della chiave di cifratura, chiave che se andasse persa renderebbe i files/documenti inaccessibili.

Nella figura seguente i files cifrati sono evidenziati dal colore verde e l’icona che ne definisce la tipologia è caratterizzata da un lucchetto chiuso.

Ma qual’è l’identità che ha accesso ai files di PITRE? Abbiamo visto nei post precedenti che è l’utente di servizio PITRE_UtenteServizio utilizzato dall’application pool associato alla web app PITRE BackEnd.

Ora vediamo come funziona EFS:

La cifratura avviene per mezzo di una chiave che viene a sua volta cifrata tramite un certificato digitale, gestito da CA Microsoft, rilasciato all’Utente gMSA che ha così la possibilità di cifrare qualsiasi file presente su disco. Viene anche generato un certificato Data Recovery Agent che garantisce la decifratura dei files anche nel caso di perdita o distruzione del certificato utente gMSA. Il certificato dell’utente gMSA con cui viene cifrata la chiave di cifratura ed il certificato DRA devono essere esportato e custoditi in un luogo sicuro.
Il BackEnd di PITRE eredita la stessa proprietà di cifratura grazie all’identità configurata nel suo application pool. I documenti che vengono acquisiti vengono scritti su file server e cifrati automaticamente da EFS.
Il FronEnd visualizza il documento tramite appositi servizi del BackEnd che controllano anche la visibilità applicativa descritta in precedenza.

mario_servino · 20 Gennaio 2023, 8:44am

Accedendo ad un file cifrato, in questo esempio un documento PDF, il sistema risponde con questo errore:

Qualora sia necessario eseguire backup periodici del file server contenente i documenti PITRE cifrati, assicurarsi che il tool di backup sia in grado di gestire i files cifrati.

mario_servino · 26 Gennaio 2023, 5:16pm

PITRE reportistica: Sql Server Report Services

In questo post la sicurezza riguarda la separazione dei servizi di gestione documentale e protocollo da quelli di reportistica che in genere l’utente finale chiede di adattare alle proprie esigenze.

Nella figura seguente, nello schema architetturale PITRE ho inserito un server su cui è installato il servizio di SQL Server Report Services su cui ho creato alcuni reports di comune utilizzo.

L’interfaccia web che ho realizzato è semplice e presenta un elenco di link ai reports disponibili.

I reports si possono parametrizzare come nell’esempio seguente dove vengono elencati i protocolli di una specifica giornata selezionando come parametri amministrazione, registro, ufficio, tipo protocollo e data di protocollo (data tra quelle presenti sui protocolli del registro). Avere la possibilità di creare un report attraverso questo servizio nativo che non richiede modifiche al codice PITRE è sicuramente un vantaggio. Un altro vantaggio è che il report si costruisce tramite un tool evoluto Report Builder che è gratuito. Il report che allego si realizza in una giornata di lavoro, ovviamente bisogna avere una buona conoscenza del data base PITRE.