Sei sulla pagina 1di 11

Architetture robuste per l’Information

Security
Un metodo per la progettazione e la verifica di architetture complesse

Andrea ing. Cecchetti - Open Consulting S.r.l.


Consultant Service Director
Maggio 2009

1
Introduzione................................................................................................................4

Analisi funzionale di un componente...........................................................................4

Progettazione  Composizione Funzionale.................................................................5

Composizioni Funzionali  Architetture Complesse....................................................9

Conclusioni................................................................................................................11

2
Open Consulting è una startup italiana nata nel Marzo del 2001, la
cui missione è abilitare e potenziare il business dei propri clienti
attraverso l’innovazione continua dei processi e degli strumenti IT.

Per rendere sostenibile l’innovazione, Open Consulting propone la


sinergia di strumenti open source con i più blasonati prodotti di mercato.

I punti fermi dell’innovazione offerta da Open Consulting sono:


• Virtualizzazione e Next Generation Data Center

• Service Oriented Architecture e Grid Computing

• Cloud Computing & Cloud Infrastructure

• Information Security

• Business Startup e Project Portfolio Management

3
Introduzione
Diversi standard di Information Security Management (elenco) si soffermano
sull’importanza della robustezza e della completezza delle implementazioni
infrastrutturali di security, senza però suggerire un metodo formale per
raccoglierle ed valutarle.
In questo articolo viene presentata una metodologia sviluppata a partire
dall’esperienza maturata durante l’attività di analisi funzionale svolta
all’interno della progettazione e realizzazione di diverse architetture di
riferimento e indirizzata a colmare la lacuna presente nei diversi standard di
ISM.
Per semplificare la comprensione della metodologia viene utilizzato lo stesso
modello di mappe cognitive (mind map, riferimento) scelto per condurre
l’analisi funzionale per la sua capacità di rappresentare graficamente le
relazioni funzionali delle componenti analizzate.

Analisi funzionale di un componente


L’analisi funzionale di un’architettura permette di valutarne la robustezza e
la completezza durante la fase progettuale, quando l’infrastruttura che la
materializza non è stata ancora realizzata, nonché di indirizzare la fase di
valutazione a posteriori della realizzazione (ex-post).
Nell’approccio proposto prendiamo a riferimento il modello in cui gli input
funzionali sono i requisiti (obbligatori o facoltativi) attraverso i quali il
componente architetturale produce gli funzionali che lo caratterizzano.
Utilizzando il metodo delle mind map possiamo analizzare ad esempio il
componente di messa in sicurezza dei dispositivi client (figura successiva)

catalogando i parametri di input (Require) in classi che vanno da Politica


(Company Policies) a Componente (Software Agent), passando per Processo
(User Provisioning).
4
Allo stesso modo la schematizzazione dei risultati in output (Provide)
permette di comprendere che oltre la funzione principale del componente
(quella di autorizzare l’utente all’uso delle perferiche), lo stesso deve
produrre segnalazioni di allarme nel caso di tentativi d’uso non autorizzati.

Progettazione  Composizione Funzionale


Nella progettazione di una soluzione di security spesso viene preso in
considerazione il solo aspetto di robustezza derivante dalla robustezza delle
implementazioni tecnologiche che sono a disposizione.
Seppur di non trascurabile importanza, questo aspetto è solo parziale
quando pensiamo alla robustezza come al rispetto di tutti i vincoli funzionali
imposti dall’analisi progettuale: una debolezza implementativa difatti può
essere corretta con minor rischio di fallimento rispetto a un errore in fase
progettuale.
Prendiamo ad esempio il componente presentato precedentemente ed
analizziamo i risultati di una progettazione che non tenga conto dei
parametri di input definiti e quindi della corretta composizione con ulteriori
parti funzionali che possono o meno ritrovarsi implementati in un solo
componente infrastrutturale.
Per facilitare l’analisi associamo al componente la sua “funzione
caratteristica”.

EPS: (Policies,UsrProv,Agent,IdRep,RBAC,CentralMgmt) 
(usrAutz,PassPol,Log,Alarm)

Dominio Codomio
Politica Processo
Processo Politica
Componente Dati
Processo Dati
Politica
Processo

Ammettendo che sia possibile trascurare uno dei parametri d’ingresso, ad


esempio perché non si ha a disposizione un processo di user provisioning, o
intendendo altresì che non sia implementato il componente nell’architettura
reale, quello che si ottiene è una funzione parzialmente applicata che può
essere interpretata come una versione sospesa o incompleta del
componente architetturale.
A livello implementantivo questa incompletezza può essere trascurata in
termini di funzionamento, ma a livello di processo la soluzione complessiva
soffrirà di una debolezza intrinseca: senza un corretto allineamento fra base
utenti e policy di accesso, alcune vulnerabilità potrebbero essere sfruttate
per annullare gli effetti benefici della contromisura adottata.
Compreso questo semplice esempio, diventa evidente l’equivalenza fra la
progettazione di sistemi complessi e la composizione funzionale degli stessi
componenti rappresentati con il modello Require/Provide.

Volendo chiarire con un esempio più complesso, utilizziamo per il nostro


scopo la progettazione di un’architettura d’Identity & Access Management.
Di seguito sono rappresentati i modelli Require/Provide delle due
componenti architetturali di Identity ed Access.
La separazione in due componenti è necessaria poiché la componente di
Access Management è, di solito, realizzata internamente dalle

5
applicazioni/soluzioni in campo (e.g. LDAP, A/D, DBMS) al contrario della sua
controparte di Identity Management che risulta quasi totalmente assente a
priori dell’implementazione di una soluzione di IAM.

Provando ad analizzare i prerequisiti funzionali che accompagnano l’Access


Management vediamo la presenza di 4 requisiti non tecnologici:
• Company Policies, necessarie per individuare il giusto livello di aderenza
della soluzione che dovrà essere implementata (vedi Privacy, Livello di rischio
operativo, etc.) al cogente, espressa ad esempio in termini di requisiti per il
livello di sicurezza delle password o della molteplicità dei ruoli utile
nell’implementazione della regola del need2known.
• Business Impact Analysis, con la quale si devono determinare la sensibilità
rispetto al business delle applicazioni e dei sistemi coinvolti dal progetto di IAM al
fine di dare la giusta priorità alle attività sui diversi sistemi.
• Business Requirement, che in realtà funzionano spesso da fattori di
rilassamento di alcune policy, che se attuate troppo restrittivamente trasformano
la sicurezza da abilitatore ad ostacolo.
• RBAC Policy Management, ovvero la necessaria realizzazione di un
processo capace di creare e gestire Ruoli ed Identità e realizzare così la corretta
separazione dei compiti (Separation of duties).

e due requisiti tecnologici:

• User Provisioning, implementato a supporto del processo di gestione delle


identità, realizzando la disseminazione delle utenze verso lo strato applicativo
(fondamentalmente applicazioni e data source) e sistemistico.
• Identity Repository, ovvero un unico componente (fisico o virtuale non ha
importanza) che sia fonte autoritativa delle identità digitali degli utenti.

6
Ammettendo, per assurdo, di poter tralasciare con leggerezza i requisiti non
tecnologici (il che causerebbe scelte concettualmente sovra- o sotto-
dimensionate e inapplicabili dal punto di vista del rispetto delle funzionalità
di business) esaminiamo cosa si rischia dal punto di vista della robustezza e
della completezza dell’architettura progettata, quando questa viene
realizzata sul campo:
1. Senza la funzione di User Provisioning, si ottengono insiemi temporalmente
disgiunti di utenti.
a. La ritardata propagazione verso i sistemi applicativi di un utente a seguito
delle sue dimissioni dal dipartimento delle risorse umane, causerebbe la
trasformazione degli account zombie in punti di vulnerabilità a causa ad esempio
del mancato cambiamento periodico della password.
b. La mancata riconciliazione di utenze asimmetriche (cancellate per cambio
di ruolo da un sistema, ma non da un altro) causa a lungo termine il mancato
rispetto della regola del need-to-known con conseguente esposizione delle
informazioni al rischio di divulgazione non controllata.

2. Senza il componente di User Repository, che nel caso realizzazione


attraverso fusione di diverse basi informative chiameremo “Identity META-Vault”,
si manifestano gli effetti collaterali della mancata gestione degli “utenti locali”,
ovvero quelli classicamente utilizzati per necessaria elasticità durante il test delle
applicazioni e generalmente non propagati verso il repository centrale.
a. La mancata completezza dei log di accesso causa la perdita di coerenza
dei risultati di Audit.
b. La presenza di utenti di test, utilizzati nell’uso comune da più persone,
vanifica l’attuazione di qualsivoglia tentativo di realizzazione del Role Base
Access Control.

Vediamo ora come dall’analisi dal modello di riferimento adottato per la


componente di Identity Management si ricava la necessità di implementare
contestualmente le due componenti costituenti lo IAM.

Le caratteristiche di output del modello (Provide) del componente di IM


7
soddisfano uno dei requisiti di input del componente di AM (User
Provisioning) e rafforzano i processi di “User Lifecycle Management”.
I requisiti dello stesso componente rafforzano altresì la necessità di alcuni
repository già evidenziati come necessari nell’analisi del componente di
Access Management:
• User Repository;
• Group Repository.

Mentre è chiara la necessità di un'unica fonte autoritativa per le identità


digitali, il “Group Repository” è un componente che viene spesso
sottovalutato, ma che in realtà riveste un ruolo fondamentale sia
nell’implementazione del Role Base Access Control che nella scrittura di
policy di accesso conformi con le più comuni norme di separazione dei ruoli,
anche in caso di accesso discrezionale alle risorse.

Tra i requisiti opzionali troviamo oltre al Management Centralizzato anche la


compatibilità dell’eventuale agente software con gli applicativi, i DB e i
Sistemi Operativi su cui dovrà essere installato. Il fatto che il requisito sia
opzionale non indica che può non essere realizzato un sistema ad agenti,
ma piuttosto che alcune implementazioni possano essere realizzate con
connettori diretti piuttosto che con agenti.

Nel diagramma riportato di seguito si vede graficamente come i due


componenti di IM & AM si combinano per formare un’architettura di IAM
solida e ben fondata.

8
Composizioni Funzionali  Architetture Complesse
È utile introdurre un’analogia fra le architetture di security ed i motori a
combustione interna, per comprendere meglio il punto di vista di un
progettista che approccia la complessità a partire da una visione d’insieme.
Nessun progettista di motori penserebbe mai di progettare il proprio motore
a partire dall’analisi delle reazioni che danno luogo alla pressione interna del
cilindro è che creano il moto alternativo del pistone. Alcuni fattori specifici, i
cosiddetti elementi termodinamici, sono noti e sostituisco in tutto e per tutto
i “fattori fisici locali” poiché ne prendono in considerazione il funzionamento
d’insieme (e.g. Pressione Interna Media, Rapporto di Compressione,
Alesaggio, Corsa).

Diversamente, quando si approccia la progettazione di architetture di


security, le stesse vengono spesso analizzate e pensate in termini degli
elementi microscopici che le costituiscono, perdendo di vista il quadro
d’insieme a favore di una eccessiva attenzione alla specifica funzionalità.
In questo modo si perde, di fatto, la visione di alto livello che permette di
legare le policy, le necessità di business, i livelli di servizio ed i processi già
in essere agli specifici dettagli dell’implementazione e si riduce così
l’insieme degli elementi di una architettura di sicurezza a un fattore di
impedimento rispetto all’operatività del sistema informativo.

Il modello proposto cerca di guidare il progettista negando il moto additivo


delle infrastrutture di security, quello per cui si aggiungono di volta in volta
componenti specifici e necessari per coprire vulnerabilità che si presentano
diluite nel tempo, riportando l’integrazione e la robustezza al centro del
processo di progettazione.
Utilizzando i modelli proposti come riferimento per assessment di sicurezza,
esiste un immediato vantaggio nella possibilità di visualizzare eventuali
errori già nei primi passi dell’analisi senza lasciare questo compito alle
9
capacità deduttive dell’analista.

La figura precedente illustra intuitivamente i risultati di un ipotetico


assessment dell’attuale architettura di IAM a cui è stato aggiunto un
componente di Network Access/Admission Control.
Come si nota, alcune componenti opzionali nel ramo dei requisiti non sono
pienamente coperte dall’attuale architettura:
• è assente o incompleta la “Classificazione dei servizi”, il che non permette
la creazione di regole robuste di profilatura degli utenti e la corrispondente
attivazione delle policy di accesso;
• la compatibilità degli agenti software non è completa del dei livelli
“sistema operativo” e “data source”, ma probabilmente viene attuata una
politica di provisioning attraverso SSH e/o Datalink.

10
Conclusioni

Osservando la figura riportata di seguito, si può avere un’idea di quali altri


modelli architetturali sono stati sviluppati e successivamente raffinati
attraverso l’applicazione pratica del modello in contesti Enterprise.

Si è cercata un’organizzazione visiva dei


modelli ponendo in alto i pattern più
concettuali (Management, Assessment, SOA)
e spostando progressivamente verso il basso
i modelli più infrastrutturali per terminare con
un modello per la messa in sicurezza degli
ambienti visualizzati, oggi tanto di moda nei
Next Generation Data Center.

Procedendo con l’applicazione del metodo


proposto e utilizzando i modelli selezionati
(ne esistono in realtà un numero pari alle
discipline in cui viene normalmente suddivisa
la sicurezza delle informazioni) è possibile
dar vita ad un’architettura di Enterprise
Security robusta.

Come illustrato, utilizzando un metodo


complementare a quello della progettazione
si può creare un efficiente strumento di
assessment che aiuterà gli Auditor a
comporre efficacemente le basi di un modello
di Enterprise Risk Management.

Futuri sviluppi del modello stanno prendendo


la direzione della valutazione dell’effetto
domino nella compromissione della
robustezza dei singoli componenti di
architetture complesse.

11