![Show Menu](styles/mobile-menu.png)
![Page Background](./../common/page-substrates/page0078.jpg)
EMBEDDED
MAGGIO
78
SOFTWARE
|
INDUSTRY 4.0
mentazione conforme. In particolare, la separa-
zione dei dati è essenziale per garantire l’accessi-
bilità solo a chi ne è autorizzato. A questo punto
val la pena sottolineare che i dati sono l’elemento
che consentono un funzionamento corretto e si-
curo delle applicazioni IIoT. Di conseguenza il
valore intrinseco del sistema è generato nei punti
terminali (endpoint), sia che si tratti di un data-
base contabile o della lettura del valore di tempe-
rature fornito da un sensore.
Per non compromettere fonti di dati così etero-
genee, un’applicazione IIOT deve non solo forni-
re alla tecnologia OT i livelli di protezione, resi-
À 8
i livelli di riservatezza e protezione in modo da
proteggere in modo adeguato la tecnologia IT.
Quest’ultima, dal canto suo, dovrà assicurare
livelli di resistenza e sicurezza più elevati per
garantire le eccellenti caratteristiche di riserva-
À 8
tecnologia stessa. Tutto ciò potrebbe essere re-
alizzabile se tutti questi sistemi interconnessi
fossero realizzati a partire da zero prevedendo
questo modello di connettività. Ovviamente non
si tratta di un’ipotesi percorribile. Un approccio
migliore è proteggere i punti terminali per mezzo
di un gateway basato sul concetto di kernel a se-
parazione (SK - Separation Kernel).
Separation Kernel
Sebbene un approccio di questi tipo è basato su
principi che forse rappresentano una novità per
il settore industriale, esso è ampiamente utiliz-
zato in altri comparti. I Separation Kernel han-
no protetto informazioni riservate nei sistemi di
comunicazione governativi per un decennio e val
Á
accademica, che hanno reso possibile un tale suc-
cesso. Il concetto di Separation Kernel è stato in-
trodotto nel 1981 da John Rushby
(8)
, il quale sug-
geriva che esso dovrebbe essere formato da “una
combinazione di hardware e software che per-
metta l’implementazione di più funzioni sfrut-
À
dar luogo a interferenze mutue non desiderate”.
Queste argomentazioni sono state convincenti a
tal punto che il principio del Separation Kernel
costituisce la base dell’iniziativa MILS (Multiple
Independent Levels of Security). In modo del tut-
to analogo, circa trent’anni fa, Saltzer e Schro-
eder
(9)
affermavano che “ogni programma e ogni
utente del sistema dovrebbero agire utilizzando
l’insieme minimo di privilegi necessari per porta-
re a termine il proprio compito “.
Questo approccio che utilizza il concetto di “Least
Privilege” (minimo privilegio) diventa inderoga-
bile laddove sono presenti applicazioni contrad-
distinte da differenti livelli di criticità che girano
a stretto contatto le une con le altre. I concetti di
Separation Kernel e Least Privilege sono quindi
focalizzati sui vantaggi della modularità, con il
primo che fa riferimento alle risorse e il secon-
do che fa riferimento alla funzionalità del siste-
ma - un aspetto tenuto in considerazione anche
da Levin, Irvine e Nguyen nel loro paper “Least
Privilege in Separation Kernels”
(10)
dove hanno
proposto un mix tra i due concetti. N
À
3 è schematizzata l’applicazione del principio del
minimo privilegio ai
“Subjects” (entità at-
tive eseguibili) e “Re-
sources” (risorse) che
sono sovrapposti ai
blocchi del Separation
Kernel, evidenzian-
do la granularità del
Á
livello di risorse e di
soggetto.
Fig. 2 – Rappresentazione
dei “Functional Domains”
e dei “ Viewpoints”(7)
previsti dal modello IIC