Table of Contents Table of Contents
Previous Page  78 / 84 Next Page
Information
Show Menu
Previous Page 78 / 84 Next Page
Page Background

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