NETWORK SECURITY

Zero Trust Security: l’architettura decisionale per autorizzare l’accesso alla rete a utenti e servizi

Autorizzare un utente o un servizio ad accedere all’infrastruttura di rete aziendale non deve essere mai fatto con leggerezza: ogni flusso o richiesta deve essere il risultato di una decisione ponderata. Ecco come funziona l’architettura decisionale di una rete Zero Trust Security

Pubblicato il 02 Gen 2023

Marco Di Muzio

InfoSec / SysEng consultant and instructor

ZTS architettura decisionale

L’autorizzazione è probabilmente il fattore più importante all’interno di un’architettura di rete Zero Trust Security (ZTS) e, in quanto tale, autorizzare un utente o un servizio non dovrebbe essere fatto con leggerezza (come spesso invece accade nei modelli di sicurezza tradizionali ancora operativi in tante, tantissime aziende, anche italiane).

Ogni flusso e/o richiesta richiede una decisione ponderata. I database e i sistemi di supporto che illustrerò sono i sistemi chiave che occorrono per prendere e influenzare tali decisioni: sono fondamentali per il controllo degli accessi, quindi devono essere rigorosamente isolati.

Occorre fare un’attenta distinzione tra queste responsabilità, in particolare quando si decide se comprimerle in un unico sistema, cosa che generalmente dovrebbe essere evitata (se possibile). Concentriamoci, quindi, sull’architettura di alto livello illustrando i componenti necessari per prendere decisioni in una rete ZTS, nonché su come si adattano e applicano tali decisioni.

Zero Trust Security: cos’è, quali sono i principi cardine e i fondamenti applicativi

Componenti dell’architettura decisionale di una rete ZTS

Un rete ZTS comprende quattro componenti principali, come mostrato nella figura seguente:

  1. Enforcement;
  2. Policy engine;
  3. Trust engine;
  4. Data stores.

Questi quattro componenti hanno responsabilità differenti e, di conseguenza, dovrebbero essere trattati come sistemi separati, ergo, isolati l’uno dall’altro, prestando particolare attenzione alla loro posizione, locazione e sicurezza informatica.

Il componente Enforcement è presente in gran numero in tutto il sistema, ed è il più vicino possibile al carico di lavoro.

È quello che incide maggiormente sull’esito delle decisioni di autorizzazione, e in genere si manifesta come un sistema di bilanciamento del carico (load balancer), una batteria di proxy e/o di firewall.

Questo componente interagisce con il Policy engine, che verrà utilizzato per prendere la decisione effettiva.

Il componente Enforcement garantisce che i client vengano autenticati, e passa il contesto di ogni flusso/richiesta al Policy engine. A sua volta, il Policy engine confronta la richiesta e il relativo contesto con i criteri, informando il responsabile dell’applicazione se la richiesta è stata o meno consentita.

Il Trust engine è utilizzato dal Policy engine per scopi di analisi dei rischi. Sfrutta più fonti dati per calcolare un punteggio di rischio (“risk score”), similmente a un punteggio di credito. Questo punteggio può essere utilizzato per combattere minacce informatiche sconosciute, aiutando a mantenere le policy efficaci, senza complicarle con firme e casi limite.

Viene utilizzato dal Policy engine come componente aggiuntivo mediante il quale è possibile prendere una decisione di autorizzazione. Infine sono presenti i vari archivi di dati (Data store) che rappresentano “fonte di verità” per i dati utilizzati per definire l’autorizzazione.

Utilizzando bit di dati autenticati come chiavi di ricerca primarie (ad esempio, un nome utente o il numero seriale di un dispositivo), questi dati vengono utilizzati per realizzare un quadro contestuale completo di un particolare flusso di richiesta.

I data store, siano essi dati dell’utente, del dispositivo o di altro, sono ampiamente sfruttati sia dal Policy engine che dal Trust engine, e rappresentano il supporto su cui verranno misurate tutte le decisioni.

Il componente Enforcement

Il componente Enforcement è il punto di partenza: sua è la “prima linea” del flusso autorizzativo, e continuerà ad essere responsabile dell’espletamento delle decisioni prese dal resto dell’architettura decisionale.

L’Enforcement si avvale di due fasi. In prima battuta verifica l’interazione con il Policy engine, ed è in questa fase che viene presentata la richiesta di autorizzazione (ad esempio, un bilanciatore che riceve una richiesta e che dovrà sapere se è stata o meno autorizzata).

Nella seconda fase avverrà l’installazione effettiva e l’applicazione della policy. Sebbene queste due fasi rappresentino un singolo componente nel mondo delle architetture ZTS, è possibile scegliere se evaderle insieme o separatamente.

Il modo in cui sceglierai di gestire l’Enforcement dipenderà probabilmente dal tuo use case. Ad esempio, un proxy che verifica l’Identità potrà contattare il Policy engine per autorizzare attivamente una richiesta che ha ricevuto e, allo stesso tempo, utilizzare la risposta a entrambi i servizi piuttosto che rifiutare la richiesta. In alternativa, un servizio di pre-autorizzazione potrebbe ricevere una richiesta di accesso a un particolare servizio, che quindi contatterà il Policy engine per l’autorizzazione.

A seguito di autorizzazione affermativa, il servizio potrà manipolare le regole del firewall locale per consentire la richiesta specifica.

Con questo approccio ci affidiamo a meccanismi di enforcement “standard” che sono pilotati dal piano di controllo ZTS. Va notato, tuttavia, che lato client questo approccio richiede di notificare al piano di controllo la richiesta di autorizzazione.

Questo aspetto può essere o meno accettabile a seconda del piano di controllo sui dispositivi e applicazioni.

Il corretto posizionamento del componente Enforcement è fondamentale poiché rappresenterà il tuo avamposto di controllo all’interno del piano dati, e pertanto devi assicurarti che i componenti delle applicazioni siano posizionati il più vicino possibile agli endpoint.

In caso contrario, il livello di “trust” potrebbe raggrupparsi dietro il componente Enforcement, minando la sicurezza ZTS. Fortunatamente il componente Enforcement può essere modellato come una sorta di client, nonché liberamente applicato in tutto il sistema, ma questo è apertamente in contrasto con il resto dei componenti di autorizzazione, che sono modellati come servizi.

Il componente Policy engine

È il componente a cui è stato assegnato il potere di prendere decisioni: lo fa confrontando la richiesta in arrivo (dal componente Enforcement) con la policy, al fine di determinare se la richiesta è o meno autorizzata. Una volta terminato il confronto, il risultato è restituito al componente Enforcement per l’effettiva realizzazione della policy.

La disposizione dei layer di Enforcement e del Policy engine consente di prendere decisioni dinamiche e puntuali, concedendo un’eventuale rapida revoca. Pertanto è importante che questi componenti siano gestiti separatamente e indipendentemente. Questo non vuol dire, tuttavia, che non possano essere collocati in maniera congiunta.

A seconda di una serie di fattori è possibile trovare un Policy engine ospitato accanto al componente di Enforcement: un esempio potrebbe essere un load balancer che autorizza le richieste tramite comunicazioni inter-processo (IPC) piuttosto che chiamate remote.

Il vantaggio più interessante di questo modello architetturale consiste nella minor latenza che occorre per autorizzare la richiesta. Un sistema di autorizzazione a bassa latenza consente un’autorizzazione dettagliata e completa dell’attività di rete; ad esempio, le singole richieste HTTP potrebbero essere autorizzate al posto dell’autorizzazione a livello di sessione che normalmente viene applicata.

È più opportuno mantenere l’isolamento a livello di processo tra il Policy engine ed il layer di Enforcement. Il componente Enforcement trovandosi nel percorso dati dell’utente, è più esposto: pertanto, integrando il Policy engine nello stesso processo potrebbe esporlo a rischi indesiderati.

L’implementazione del Policy engine come processo a sé stante contribuisce notevolmente a garantire che i bug nel livello di applicazione non comportino una compromissione delle policy.

Occorre anche memorizzare le regole referenziate dal Policy engine.

Le regole espresse dalle policy devono essere configurate nel Policy engine, ma è vivamente consigliato acquisire le regole dall’esterno del Policy engine stesso. Salvare le regole delle policy in un sistema di controllo delle versioni (VCS) è l’ideale, e apporta diversi benefici:

  1. le modifiche alle policy potranno essere monitorate nel tempo;
  2. le motivazioni che hanno portato alla modifica della policy in esame vengono tracciate puntualmente nel sistema VCS;
  3. lo stato previsto dalla policy corrente potrà essere convalidato rispetto all’applicazione effettiva dei pattern di Enforcement.

Molti di questi vantaggi, storicamente sono stati implementati utilizzando rigorose procedure di change management. Con un tale meccanismo, le modifiche alla configurazione del sistema verranno richieste e approvate prima di essere applicate.

Il log del sistema di change management risultante potrà essere utilizzato per determinare perché il sistema si trova nello stato attuale.

Spostare le definizioni delle policy all’interno di un VCS è la logica conclusione delle procedure di change management quando il sistema può essere configurato con poche righe di scripting. Invece di fare affidamento sui sysadmin (al di là delle eventuali certificazioni conseguite, quanti sono realmente affidabili, tempestivi e precisi?) per configurare la policy desiderata nel sistema, possiamo acquisire la policy come “dati” che un programma potrà caricare e applicare agilmente.

In un certo qual senso, quindi, caricare le policy sarà quindi simile alla distribuzione di software.

Di conseguenza i sysadmin potranno utilizzare le consuete procedure di distribuzione software (pipeline e affini) per gestire variazioni di policy.

Le policy in una rete ZTS sono granulari, meticolose. Il dettaglio di granularità varia in base alla complessità della rete, ma l’obiettivo desiderato è che le policy che hanno come ambito singole risorse da proteggere, vengano doverosamente applicate e tracciate.

Il modello ZTS inizia a divergere dalla tradizionale sicurezza perimetrale già nei meccanismi di controllo utilizzati per definire le policy: invece di definire la policy in termini di dettagli d’implementazione (indirizzi IP e intervalli), la policy è definita assai più approfonditamente in termini di componenti logici nella rete.

Questi componenti sono costituiti da:

  1. servizi di rete;
  2. classi di device endpoint;
  3. ruoli degli utenti.

La definizione delle policy dai componenti logici esistenti nella rete ZTS consente al Policy engine di calcolare le decisioni di Enforcement in base alla sua conoscenza dell’effettivo stato della rete. In termini concreti, un web service in esecuzione su un server oggi, domani potrebbe trovarsi su un server differente o persino spostarsi automaticamente come indicato da un workload scheduler.

Per adattarsi a questa realtà, le policy che definirai dovranno essere separate da questi “dettagli di implementazione”.

Un esempio di questo stile di policy tratto da un progetto Kubernetes:

(In questo esempio di Network Policy Kubernetes i criteri utilizzano delle etichette per gestire il workload, applicando le sottostanti regole basate su IP quando e dove necessario).

Le policy in una rete ZTS si basano anche sui punteggi di affidabilità (“trust scores”) per rilevare (e possibilmente anticipare) eventuali vettori di attacco sconosciuti. Definendo la policy con un punteggio di attendibilità, i sysadmin saranno in grado di mitigare i rischi che viceversa potrebbero non essere rilevati con una tradizionale policy specifica.

Le policy ovviamente non faranno affidamento solo sul punteggio di affidabilità: nella definizione delle policy potranno far parte anche caratteristiche peculiari della richiesta che deve essere autorizzata. Un esempio di questo scenario potrebbe essere costituito da determinati ruoli utente a cui si decide di fornire accesso solo e soltanto ad un determinato servizio in orari e giorni predefiniti da una determinata postazione censita.

Chi definisce le policy? Le policy di una rete ZTS devono essere granulari, il che significa dover imporre un onere straordinario ai sysadmin per mantenere aggiornate le policy. Per distribuire il carico di queste configurazioni, la maggior parte delle aziende decide di distribuire la definizione delle policy tra i team, in modo che possano contribuire proattivamente a mantenere le policy per i servizi in loro gestione.

Tuttavia, consentire a un’intera organizzazione la (ri)definizione delle policy comporta alcuni potenziali rischi, come ad esempio utenti in buona fede che creano policy lasche, aumentando così la superficie di attacco del sistema che intendevano limitare.

Le reti e i sistemi ZTS si basano su due flussi di lavoro organizzativi per contrastare questa esposizione.

In primo luogo, poiché le policy vengono in genere archiviate mediante sistemi VCS, collaborare con un’altra persona che rianalizzi le modifiche alle policy migliora la possibilità che le modifiche stesse siano ben strutturate.

I team SOC potranno così analizzare le richieste di modifica e porre eventuali domande investigative per garantire che la policy in esame sia la più stretta possibile.

La seconda misura organizzativa utilizzabile consiste nel sovrapporre una policy dell’infrastruttura ampia ad una policy certosina. Ad esempio, un gruppo di infrastrutture potrebbe giustamente richiedere che solo un determinato insieme di ruoli sia autorizzato ad accettare il traffico da Internet piuttosto che da una determinata subnet.

Il team dell’infrastruttura definirà quindi la policy che impone tale restrizione, e nessuna policy definita dall’utente verrà autorizzata ad aggirarla. L’applicazione di questo vincolo potrebbe assumere diverse forme: un test automatizzato della policy proposta, piuttosto che un Policy engine che rifiuti categoricamente istanze di policy eccessivamente lasche provenienti da fonti non attendibili. Tale applicazione può essere utile anche per la conformità e i requisiti normativi.

Il componente Trust engine

In una rete ZTS il componente Trust engine esegue l’analisi dei rischi di una particolare richiesta o azione. La responsabilità di questo componente è quella di produrre una valutazione numerica della “rischiosità” di eseguire una particolare richiesta o azione, rischiosità che a sua volta il Policy engine utilizzerà per prendere una decisione definitiva sull’autorizzazione.

Il Trust engine estrae spesso dati contenuti negli inventari e/o nei sistemi di asset management al fine di verificare gli attributi di un’entità durante il calcolo del suo punteggio.

Un inventario dei dispositivi, ad esempio, può fornire al Trust engine informazioni chiave come l’ultima volta che un dispositivo è stato verificato, oppure se quel certo dispositivo dispone di una particolare funzionalità di sicurezza hardware.

Creare una valutazione numerica del rischio non è un compito banale. Un approccio semplicistico è quello di definire un insieme di regole ad hoc che valutino la rischiosità di un’entità, di un asset o di un utente. Ad esempio, un dispositivo a cui mancano le ultime patch software potrebbe subire una riduzione del punteggio.

Allo stesso modo, un utente che spesso non riesce ad autenticarsi potrebbe subire un’automatica riduzione del punteggio di affidabilità. Sebbene il punteggio di attendibilità ad hoc è semplice da implementare, un insieme di valori e regole definite staticamente saranno insufficienti per raggiungere l’obiettivo desiderato, ossia quello di difendersi da attacchi imprevisti.

Di conseguenza, oltre a utilizzare regole statiche, in ambienti professionali per derivare le funzione di punteggio di norma vengono utilizzati Trust engine abbinati a tecniche di Machine Learning (ML).

Sfruttando il ML è possibile ottenere una funzione di punteggio (di rischiosità) calcolando fatti osservabili da un sottoinsieme di dati di attività noti come dati di addestramento. I dati di addestramento sono osservazioni non elaborate che sono state associate a entità attendibili o non attendibili.

Da questi dati, le caratteristiche vengono estratte e utilizzate per ricavare una funzione di punteggio generata computazionalmente.

Questa funzione di punteggio, un modello in termini di ML, viene quindi applicata su di un insieme di dati nello stesso formato dei dati di addestramento.

I punteggi risultanti vengono confrontati con le valutazioni del rischio definite dall’analista, e la qualità del modello può quindi essere perfezionata in base alla sua capacità di prevedere il rischio dei dati analizzati.

Sebbene il ML sia sempre più utilizzato, ciò non elimina la necessità di definire regole più esplicite nel Trust engine. A causa della limitazione dei modelli di punteggio derivati – o per le personalizzazioni desiderate della funzione di punteggio – i Trust engine utilizzano in genere una combinazione di metodi di punteggio ad hoc e di ML.

Decidere quali componenti di una rete ZTS debbano essere valutati è una questione che richiede più di qualche riunione: i punteggi devono essere calcolati per ogni singola entità (utenti, dispositivi e applicazioni), per l’agent di rete nel suo insieme o per entrambi? Diamo un’occhiata ad alcuni scenari.

Immagina che le credenziali di un utente possano essere forzate (ad esempio con un attacco a forza bruta) da un attacker. Alcuni sistemi mitigheranno questa minaccia bloccando l’account dell’utente.

Se dovessimo assegnare un punteggio negativo a un utente in base a quest’attività, una rete ZTS soffrirebbe dello stesso problema.

Un approccio migliore consiste nel rendersi conto che stiamo autenticando l’agent di rete, e quindi l’agent dell’attacker verrà neutralizzato, lasciando intatto l’agent di rete dell’utente legittimo.

Questo esempio dimostra come sia l’agent di rete la giusta entità a cui dovrebbe essere assegnato il punteggio in questo scenario.

Ma il solo punteggio dell’agent può non essere sufficiente contro altri vettori di attacco. Consideriamo un dispositivo che è stato associato ad attività dannose. L’agent di un utente su quel dispositivo potrebbe non mostrare segni di comportamenti sospetti, ma il fatto che l’agent venga formato con un dispositivo sospetto dovrebbe chiaramente avere un impatto sul punteggio di affidabilità per tutte le richieste provenienti da quel dispositivo.

Questo scenario ci suggerisce fortemente che il dispositivo dovrebbe essere schedato.

Infine, bisogna considerare che un insider (la famigerata minaccia interna) potrebbe utilizzare più dispositivi per esfiltrare segreti commerciali o brevetti industriali. Mentre l’insider passa da un dispositivo all’altro (come negli scenari dei lateral movement), ci piacerebbe che l’algoritmo di affidabilità (utilizzato dal Trust engine) riconoscesse questo comportamento, e riflettesse un livello di affidabilità decrescente nel punteggio di affidabilità per tutte le future decisioni di autorizzazione.

Anche in questo caso, il punteggio dell’agent da solo non è sufficiente per mitigare le minacce comuni, infatti, nel suo insieme sembra che la soluzione più attendibile sia quella di assegnare un punteggio sia all’agent sia alle entità sottostanti che lo compongono.

Questi punteggi verranno trasmessi al Policy engine, che potrà così scegliere i componenti più adeguati da autorizzare in base alle policy definite.

Tuttavia, quando si progetta una policy, presentare così tanti punteggi che occorre prendere in considerazione potrebbe rendere il compito più difficile nonché soggetto a errori. In un mondo ideale, un singolo punteggio sarebbe sufficiente, ma tale approccio presenta ulteriori requisiti di disponibilità del Trust engine.

Un sistema che si avvale di valutazioni a punteggio singolo dovrebbe passare a un modello on-line, in cui il Trust engine verrà interrogato in modo interattivo durante il processo decisionale delle policy. Al motore verrà fornito un contesto sulla base della richiesta autorizzata, in modo che potrà scegliere la miglior funzione di punteggio per quella particolare richiesta.

Questo approccio è chiaramente più complesso da costruire e gestire, inoltre, per quelle policy in cui i sysadmin desiderano specificamente gestire un particolare componente (ad esempio, consentire solo implementazioni da dispositivi con un punteggio superiore a X), questo metodo risulta piuttosto indiretto.

Sebbene i punteggi assegnati alle entità in una rete ZTS non siano considerati riservati, si dovrebbe evitare di esporre i punteggi agli utenti finali del sistema.

Poter visionare il proprio punteggio potrebbe avvantaggiare aspiranti attacker che stanno pianificando un attacco informatico o che hanno già ottenuto un accesso ai sistemi.

Questo desiderio di nascondere i punteggi dovrebbe essere bilanciato con la frustrazione della capacità, che hanno gli utenti finali, di capire come le loro azioni stanno influenzando la loro fiducia nel sistema.

Ad esempio, un buon compromesso nei sistemi antifrode consiste nel mostrare raramente agli utenti i loro punteggi, e parallelamente nell’evidenziare i fattori che contribuiscono alla determinazione del loro punteggio.

Il componente Data store

Gli archivi di dati (“Data stores”) utilizzati per prendere decisioni di autorizzazione costituiscono “fonti di verità” per lo stato attuale e passato del sistema.

Le informazioni provenienti da questi archivi di dati fluiscono attraverso i sistemi del piano di controllo, fornendo gran parte della base su cui vengono prese le decisioni di autorizzazione, come mostrato nella seguente figura:

Nell’apertura di questo articolo accennavo a come il Trust engine sfrutti i Data store per produrre un punteggio di attendibilità, che a sua volta alimenta il Policy engine. In questo modo, le informazioni nei Data store del Piano di controllo contattano il sistema autorizzativo, raggiungendo infine il Policy engine in cui verrà presa la decisione.

I data store sono utilizzati dal Policy engine sia direttamente che indirettamente, ma possono essere utili anche ad altri sistemi che necessitano di dati autorevoli sullo stato della rete.

Le reti ZTS tendono ad avere molti data store organizzati per funzione. Ne esistono due tipi principali: inventario e storico. Un (data store) inventario costituisce un’unica fonte coerente di verità, che registra lo stato attuale delle risorse che rappresenta.

Un esempio è un inventario degli utenti che memorizza tutte le informazioni sugli utenti piuttosto che un inventario dei dispositivi che raccoglie le informazioni sui dispositivi noti all’azienda. In un inventario esisterà una chiave primaria che rappresenta in modo univoco l’entità tracciata.

Nel caso di un utente, la scelta più probabile è il nome utente; per un dispositivo è più appropriato un numero di serie. Quando un agent ZTS viene sottoposto ad autenticazione, autentica la propria identità rispetto a questa chiave primaria nell’inventario.

Altro esempio, un utente si autentica con un dato nome utente: il Policy engine verrà a conoscenza del nome utente, e che è stato correttamente autenticato. Il nome utente viene quindi utilizzato come chiave primaria per la ricerca nell’inventario degli utenti. A seconda delle tue particolari scelte di implementazione e autenticazione, tenere a mente questo flusso e questo scopo ti aiuterà a scegliere le chiavi primarie giuste.

Un (data store) archivio è leggermente diverso. Gli archivi di dati storici vengono conservati principalmente per scopi di analisi dei rischi. Sono utili per esaminare comportamenti e modelli recenti/passati al fine di valutare il rischio in relazione a una particolare richiesta o azione.

Il Trust engine attinge a questi dati proprio perché le determinazioni di affidabilità/rischio sono la responsabilità primaria di questo componente. Si possono creare molti archivi di dati storici e, quando si tratta di Analisi dei rischi, tecnicamente parlando il limite è l’infinito. Alcuni esempi comuni includono il logging degli account utente e i dati sFlow. Indipendentemente dai dati archiviati, dovranno essere interrogabili utilizzando la chiave primaria da uno dei data store inventario. Più avanti approfondirò meglio il concetto.

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Speciale PNRR

Tutti
Incentivi
Salute digitale
Formazione
Analisi
Sostenibilità
PA
Sostemibilità
Sicurezza
Digital Economy
CODICE STARTUP
Imprenditoria femminile: come attingere ai fondi per le donne che fanno impresa
DECRETI
PNRR e Fascicolo Sanitario Elettronico: investimenti per oltre 600 milioni
IL DOCUMENTO
Competenze digitali, ecco il nuovo piano operativo nazionale
STRUMENTI
Da Istat e RGS gli indicatori per misurare la sostenibilità nel PNRR
STRATEGIE
PNRR – Piano nazionale di Ripresa e Resilienza: cos’è e novità
FONDI
Pnrr, ok della Ue alla seconda rata da 21 miliardi: focus su 5G e banda ultralarga
GREEN ENERGY
Energia pulita: Banca Sella finanzia i progetti green incentivati dal PNRR
TECNOLOGIA SOLIDALE
Due buone notizie digitali: 500 milioni per gli ITS e l’inizio dell’intranet veloce in scuole e ospedali
INNOVAZIONE
Competenze digitali e InPA cruciali per raggiungere gli obiettivi del Pnrr
STRATEGIE
PA digitale 2026, come gestire i fondi PNRR in 5 fasi: ecco la proposta
ANALISI
Value-based healthcare: le esperienze in Italia e il ruolo del PNRR
Strategie
Accordi per l’innovazione, per le imprese altri 250 milioni
Strategie
PNRR, opportunità e sfide per le smart city
Strategie
Brevetti, il Mise mette sul piatto 8,5 milioni
Strategie
PNRR e opere pubbliche, la grande sfida per i Comuni e perché bisogna pensare digitale
Formazione
Trasferimento tecnologico, il Mise mette sul piatto 7,5 milioni
Strategie
PSN e Strategia Cloud Italia: a che punto siamo e come supportare la PA in questo percorso
Dispersione idrica
Siccità: AI e analisi dei dati possono ridurre gli sprechi d’acqua. Ecco gli interventi necessari
PNRR
Cloud, firmato il contratto per l’avvio di lavori del Polo strategico
Formazione
Competenze digitali, stanziati 48 milioni per gli Istituti tecnologici superiori
Iniziative
Digitalizzazione delle reti idriche: oltre 600 milioni per 21 progetti
Competenze e competitività
PNRR, così i fondi UE possono rilanciare la ricerca e l’Università
Finanziamenti
PNRR, si sbloccano i fondi per l’agrisolare
Sanità post-pandemica
PNRR, Missione Salute: a che punto siamo e cosa resta da fare
Strategie
Sovranità e autonomia tecnologica nazionale: come avviare un processo virtuoso e sostenibile
La relazione
Pnrr e PA digitale, l’alert della Corte dei conti su execution e capacità di spesa
L'editoriale
Elezioni 2022, la sfida digitale ai margini del dibattito politico
Strategie
Digitale, il monito di I-Com: “Senza riforme Pnrr inefficace”
Transizione digitale
Pnrr: arrivano 321 milioni per cloud dei Comuni, spazio e mobilità innovativa
L'analisi I-COM
Il PNRR alla prova delle elezioni: come usare bene le risorse e centrare gli obiettivi digitali
Cineca
Quantum computing, una svolta per la ricerca: lo scenario europeo e i progetti in corso
L'indice europeo
Desi, l’Italia scala due posizioni grazie a fibra e 5G. Ma è (ancora) allarme competenze
L'approfondimento
PNRR 2, ecco tutte le misure per cittadini e imprese: portale sommerso, codice crisi d’impresa e sismabonus, cosa cambia
Servizi digitali
PNRR e trasformazione digitale: ecco gli investimenti e le riforme previste per la digitalizzazione della PA
Legal health
Lo spazio europeo dei dati sanitari: come circoleranno le informazioni sulla salute nell’Unione Europea
Servizi digitali
PNRR e PA digitale: non dimentichiamo la dematerializzazione
Digital Healthcare transformation
La trasformazione digitale degli ospedali
Governance digitale
PA digitale, è la volta buona? Così misure e risorse del PNRR possono fare la differenza
Servizi digitali
Comuni e digitale, come usare il PNRR senza sbagliare
La survey
Pnrr e digitale accoppiata vincente per il 70% delle pmi italiane
Missione salute
Fascicolo Sanitario Elettronico alla prova del PNRR: limiti, rischi e opportunità
Servizi pubblici
PNRR: come diventeranno i siti dei comuni italiani grazie alle nuove risorse
Skill gap
PNRR, la banda ultra larga crea 20.000 nuovi posti di lavoro
Il Piano
Spazio, Colao fa il punto sul Pnrr: i progetti verso la milestone 2023
FORUMPA2022
PNRR e trasformazione digitale: rivedi i Talk di FORUM PA 2022 in collaborazione con le aziende partner
I contratti
Avio, 340 milioni dal Pnrr per i nuovi propulsori a metano
Next Generation EU
PNRR, a che punto siamo e cosa possono aspettarsi le aziende private
Fondi
Operativo il nuovo portale del MISE con tutti i finanziamenti per le imprese
Servizi comunali
Il PNRR occasione unica per i Comuni digitali: strumenti e risorse per enti e cittadini
Healthcare data platform
PNRR dalla teoria alla pratica: tecnologie e soluzioni per l’innovazione in Sanità
Skill
Competenze digitali, partono le Reti di facilitazione
Gli obiettivi
Scuola 4.0, PNRR ultima chance: ecco come cambierà il sistema formativo
Sistema Paese
PNRR 2, è il turno della space economy
FORUM PA 2022
FORUM PA 2022: la maturità digitale dei comuni italiani rispetto al PNRR
Analisi
PNRR: dalla Ricerca all’impresa, una sfida da cogliere insieme
Innovazione
Pnrr, il Dipartimento per la Trasformazione digitale si riorganizza
FORUM PA 2022
PA verde e sostenibile: il ruolo di PNRR, PNIEC, energy management e green public procurement
Analisi
PNRR, Comuni e digitalizzazione: tutto su fondi e opportunità, in meno di 3 minuti. Guarda il video!
Rapporti
Competenze digitali e servizi automatizzati pilastri del piano Inps
Analisi
Attuazione del PNRR: il dialogo necessario tra istituzioni e società civile. Rivedi lo Scenario di FORUM PA 2022
Progetti
Pnrr, fondi per il Politecnico di Torino. Fra i progetti anche IS4Aerospace
Analisi
PNRR, Colao fa il punto sulla transizione digitale dell’Italia: «In linea con tutte le scadenze»
La Svolta
Ict, Istat “riclassifica” i professionisti. Via anche al catalogo dati sul Pnrr
Analisi
Spazio, Colao fa il punto sul Pnrr: i progetti verso la milestone 2023
FORUM PA 2022
Ecosistema territoriale sostenibile: l’Emilia Romagna tra FESR e PNRR
Il Piano
Innovazione, il Mise “centra” gli obiettivi Pnrr: attivati 17,5 miliardi
Analisi
PNRR: raggiunti gli obiettivi per il primo semestre 2022. Il punto e qualche riflessione
Analisi
PNRR: dal dialogo tra PA e società civile passa il corretto monitoraggio dei risultati, tra collaborazione e identità dei luoghi
Webinar
Comuni e PNRR: un focus sui bandi attivi o in pubblicazione
Analisi
Formazione 4.0: cos’è e come funziona il credito d’imposta
PA e Sicurezza
PA e sicurezza informatica: il ruolo dei territori di fronte alle sfide della digitalizzazione
PA e sicurezza
PNRR e servizi pubblici digitali: sfide e opportunità per Comuni e Città metropolitane
Water management
Water management in Italia: verso una transizione “smart” e “circular” 
LE RISORSE
Transizione digitale, Simest apre i fondi Pnrr alle medie imprese
Prospettive
Turismo, cultura e digital: come spendere bene le risorse del PNRR
Analisi
Smart City: quale contributo alla transizione ecologica
Decarbonizzazione
Idrogeno verde, 450 milioni € di investimenti PNRR, Cingolani firma
Unioncamere
PNRR, imprese in ritardo: ecco come le Camere di commercio possono aiutare
I fondi
Industria 4.0: solo un’impresa su tre pronta a salire sul treno Pnrr
CODICE STARTUP
Imprenditoria femminile: come attingere ai fondi per le donne che fanno impresa
DECRETI
PNRR e Fascicolo Sanitario Elettronico: investimenti per oltre 600 milioni
IL DOCUMENTO
Competenze digitali, ecco il nuovo piano operativo nazionale
STRUMENTI
Da Istat e RGS gli indicatori per misurare la sostenibilità nel PNRR
STRATEGIE
PNRR – Piano nazionale di Ripresa e Resilienza: cos’è e novità
FONDI
Pnrr, ok della Ue alla seconda rata da 21 miliardi: focus su 5G e banda ultralarga
GREEN ENERGY
Energia pulita: Banca Sella finanzia i progetti green incentivati dal PNRR
TECNOLOGIA SOLIDALE
Due buone notizie digitali: 500 milioni per gli ITS e l’inizio dell’intranet veloce in scuole e ospedali
INNOVAZIONE
Competenze digitali e InPA cruciali per raggiungere gli obiettivi del Pnrr
STRATEGIE
PA digitale 2026, come gestire i fondi PNRR in 5 fasi: ecco la proposta
ANALISI
Value-based healthcare: le esperienze in Italia e il ruolo del PNRR
Strategie
Accordi per l’innovazione, per le imprese altri 250 milioni
Strategie
PNRR, opportunità e sfide per le smart city
Strategie
Brevetti, il Mise mette sul piatto 8,5 milioni
Strategie
PNRR e opere pubbliche, la grande sfida per i Comuni e perché bisogna pensare digitale
Formazione
Trasferimento tecnologico, il Mise mette sul piatto 7,5 milioni
Strategie
PSN e Strategia Cloud Italia: a che punto siamo e come supportare la PA in questo percorso
Dispersione idrica
Siccità: AI e analisi dei dati possono ridurre gli sprechi d’acqua. Ecco gli interventi necessari
PNRR
Cloud, firmato il contratto per l’avvio di lavori del Polo strategico
Formazione
Competenze digitali, stanziati 48 milioni per gli Istituti tecnologici superiori
Iniziative
Digitalizzazione delle reti idriche: oltre 600 milioni per 21 progetti
Competenze e competitività
PNRR, così i fondi UE possono rilanciare la ricerca e l’Università
Finanziamenti
PNRR, si sbloccano i fondi per l’agrisolare
Sanità post-pandemica
PNRR, Missione Salute: a che punto siamo e cosa resta da fare
Strategie
Sovranità e autonomia tecnologica nazionale: come avviare un processo virtuoso e sostenibile
La relazione
Pnrr e PA digitale, l’alert della Corte dei conti su execution e capacità di spesa
L'editoriale
Elezioni 2022, la sfida digitale ai margini del dibattito politico
Strategie
Digitale, il monito di I-Com: “Senza riforme Pnrr inefficace”
Transizione digitale
Pnrr: arrivano 321 milioni per cloud dei Comuni, spazio e mobilità innovativa
L'analisi I-COM
Il PNRR alla prova delle elezioni: come usare bene le risorse e centrare gli obiettivi digitali
Cineca
Quantum computing, una svolta per la ricerca: lo scenario europeo e i progetti in corso
L'indice europeo
Desi, l’Italia scala due posizioni grazie a fibra e 5G. Ma è (ancora) allarme competenze
L'approfondimento
PNRR 2, ecco tutte le misure per cittadini e imprese: portale sommerso, codice crisi d’impresa e sismabonus, cosa cambia
Servizi digitali
PNRR e trasformazione digitale: ecco gli investimenti e le riforme previste per la digitalizzazione della PA
Legal health
Lo spazio europeo dei dati sanitari: come circoleranno le informazioni sulla salute nell’Unione Europea
Servizi digitali
PNRR e PA digitale: non dimentichiamo la dematerializzazione
Digital Healthcare transformation
La trasformazione digitale degli ospedali
Governance digitale
PA digitale, è la volta buona? Così misure e risorse del PNRR possono fare la differenza
Servizi digitali
Comuni e digitale, come usare il PNRR senza sbagliare
La survey
Pnrr e digitale accoppiata vincente per il 70% delle pmi italiane
Missione salute
Fascicolo Sanitario Elettronico alla prova del PNRR: limiti, rischi e opportunità
Servizi pubblici
PNRR: come diventeranno i siti dei comuni italiani grazie alle nuove risorse
Skill gap
PNRR, la banda ultra larga crea 20.000 nuovi posti di lavoro
Il Piano
Spazio, Colao fa il punto sul Pnrr: i progetti verso la milestone 2023
FORUMPA2022
PNRR e trasformazione digitale: rivedi i Talk di FORUM PA 2022 in collaborazione con le aziende partner
I contratti
Avio, 340 milioni dal Pnrr per i nuovi propulsori a metano
Next Generation EU
PNRR, a che punto siamo e cosa possono aspettarsi le aziende private
Fondi
Operativo il nuovo portale del MISE con tutti i finanziamenti per le imprese
Servizi comunali
Il PNRR occasione unica per i Comuni digitali: strumenti e risorse per enti e cittadini
Healthcare data platform
PNRR dalla teoria alla pratica: tecnologie e soluzioni per l’innovazione in Sanità
Skill
Competenze digitali, partono le Reti di facilitazione
Gli obiettivi
Scuola 4.0, PNRR ultima chance: ecco come cambierà il sistema formativo
Sistema Paese
PNRR 2, è il turno della space economy
FORUM PA 2022
FORUM PA 2022: la maturità digitale dei comuni italiani rispetto al PNRR
Analisi
PNRR: dalla Ricerca all’impresa, una sfida da cogliere insieme
Innovazione
Pnrr, il Dipartimento per la Trasformazione digitale si riorganizza
FORUM PA 2022
PA verde e sostenibile: il ruolo di PNRR, PNIEC, energy management e green public procurement
Analisi
PNRR, Comuni e digitalizzazione: tutto su fondi e opportunità, in meno di 3 minuti. Guarda il video!
Rapporti
Competenze digitali e servizi automatizzati pilastri del piano Inps
Analisi
Attuazione del PNRR: il dialogo necessario tra istituzioni e società civile. Rivedi lo Scenario di FORUM PA 2022
Progetti
Pnrr, fondi per il Politecnico di Torino. Fra i progetti anche IS4Aerospace
Analisi
PNRR, Colao fa il punto sulla transizione digitale dell’Italia: «In linea con tutte le scadenze»
La Svolta
Ict, Istat “riclassifica” i professionisti. Via anche al catalogo dati sul Pnrr
Analisi
Spazio, Colao fa il punto sul Pnrr: i progetti verso la milestone 2023
FORUM PA 2022
Ecosistema territoriale sostenibile: l’Emilia Romagna tra FESR e PNRR
Il Piano
Innovazione, il Mise “centra” gli obiettivi Pnrr: attivati 17,5 miliardi
Analisi
PNRR: raggiunti gli obiettivi per il primo semestre 2022. Il punto e qualche riflessione
Analisi
PNRR: dal dialogo tra PA e società civile passa il corretto monitoraggio dei risultati, tra collaborazione e identità dei luoghi
Webinar
Comuni e PNRR: un focus sui bandi attivi o in pubblicazione
Analisi
Formazione 4.0: cos’è e come funziona il credito d’imposta
PA e Sicurezza
PA e sicurezza informatica: il ruolo dei territori di fronte alle sfide della digitalizzazione
PA e sicurezza
PNRR e servizi pubblici digitali: sfide e opportunità per Comuni e Città metropolitane
Water management
Water management in Italia: verso una transizione “smart” e “circular” 
LE RISORSE
Transizione digitale, Simest apre i fondi Pnrr alle medie imprese
Prospettive
Turismo, cultura e digital: come spendere bene le risorse del PNRR
Analisi
Smart City: quale contributo alla transizione ecologica
Decarbonizzazione
Idrogeno verde, 450 milioni € di investimenti PNRR, Cingolani firma
Unioncamere
PNRR, imprese in ritardo: ecco come le Camere di commercio possono aiutare
I fondi
Industria 4.0: solo un’impresa su tre pronta a salire sul treno Pnrr

Articoli correlati

Articolo 1 di 3