Il governo degli accessi logici e della separazione dei ruoli

Il governo degli accessi logici e della separazione
dei ruoli tramite l'Identity Management
Parma, 5-6 giugno 2008
Codice documento: PSA-PP079
Abstract
La relazione illustra il progetto di introduzione di un sistema di Identity and
Access Management in una realtà aziendale complessa. L'attenzione è posta sui
fattori critici di successo del progetto IAM e sulle soluzioni organizzative e
tecniche adottate per rendere IAM l'elemento di governo degli accessi alle
applicazioni aziendali, nel rispetto dei principi del “need to know” e della
“segregation of duties”.
Viene, altresì, evidenziato come la realizzazione di IAM rappresenti uno snodo
vitale per il raggiungimento ed il mantenimento della compliance SOX.
Summary
Il contesto e le esigenze
La soluzione: il progetto
I fattori critici
Allegati
Uso: Pubblico
Il contesto e le esigenze
“La guerra è di somma importanza per lo Stato: è sul campo di
battaglia che si decide la vita o la morte delle nazioni, ed è lì che se ne
traccia la via della sopravvivenza o della distruzione. Dunque è
indispensabile studiarla a fondo.”
Sun Tzu
5-6 giugno 2008
Progetto Sicurezza Accessi
4
Uso: Pubblico
IT Enel in Italia
3 Data Centres & 1200 siti connessi
60k utenti intranet
20k utenti mainframe
40k caselle e-mail interne (>500k esterne)
13,2
l MI
13,2
l VE
l TO
8,8
23k utenti SAP/R3
12k utenti “full internet” (30k parziali)
44
30M contatori elettronici (175M operazioni remote)
13,2
l BO
8,8
20
l FI
13,2
20
28
Piattaforme per Sales & workforce management
l ROMA
CRM (~40M. Chiamate/anno).
9,6
20
4,4
Metodi di autenticazione
l NA
.
4,4
SiteMinder, Active Directory, PKI Entrust, …
Repository di identità
8
7,6
Directory X.500 (PKI), Exchange 2000, Remedy, RACF, …
Progetto Sicurezza Accessi
l BA
4
l CA
SAP, Active Directory, Oracle tables, Bea Portal Intranet,
5-6 giugno 2008
4,8
15,2
l PA
5
l CZ
Uso: Pubblico
Enel nel mondo
Europa
SLOVACCHIA
RUSSIA
• 66% di Slovenské Elektrárne: Potenza
installata 6.442 MW
• Gestione di 900MW CCGT
vicino S. Petersburg
(NWTPP)
• 49,5% di Rusenergosbyt
trader
• ~60% di OGK-5
SPAGNA
• ~24% di Endesa
• Viesgo: Potenza installata 2199MW
più di 600K clienti, 29.990 km di
linee di distribuzione
• 50% of EUFR: Potenza installata
228 MW
NORD AMERICA
• Potenza installata
402MW
ROMANIA
• 51% di Banat & Dobrogea
• 1.4M di clienti, 52.972 km di linee di
distribuzione
• 67.5% Electrica Muntenia Sud
(closing expected by 2nd half of 2007)
• 1.1M di clienti e 43,350km di linee di
distribuzione
BULGARIA
• 73% Maritza East III: Potenza
installata 560 MW
FRANCIA
America
AMERICA LATINA
• Potenza installata
471MW
• 5% Powernext MoU per lo sviluppo di EPR
• Erelis: sviluppo energia eolica
• Enel France: fornitore
5-6 giugno 2008
Progetto Sicurezza Accessi
6
Uso: Pubblico
Contesto aziendale
Il parco applicativo IT della realtà Enel è molto ampio ed eterogeneo
L’immagine “digitale” delle risorse umane consente di eseguire controlli in
modo efficace poiché in Enel tutti i processi hanno un’elevata
automazione
L’organizzazione è gestita in modo flessibile per adattarsi rapidamente
alle esigenze del mercato, perciò i cambiamenti sono frequenti e profondi
Occorre ottemperare alle disposizioni di legge, non solo italiane:
• Legge 8 giugno 2001, n. 231
• Legge 30 giugno 2003, n. 196 – “Privacy”
• Legge 28 dicembre 2005, n. 262 – “Risparmio”
• Sarbanes – Oxley Act
Per approfondimenti
5-6 giugno 2008
Progetto Sicurezza Accessi
7
Uso: Pubblico
Il cambiamento organizzativo
Distinguere la responsabilità della correttezza del trattamento
dell’informazione, da quella del raggiungimento dei risultati
• Eliminazione del contrasto di responsabilità sul medesimo soggetto
• Miglioramento della corrispondenza dei processi alla normativa
• Controllabilità delle interferenze tra processi diversi
• Aumento della flessibilità operativa
• Coinvolgimento dei responsabili operativi nelle fasi di controllo
Responsabilità
sulle persone
Responsabilità
su dati e processi
5-6 giugno 2008
Progetto Sicurezza Accessi
User Manager
Data Owner
8
Uso: Pubblico
La soluzione: il progetto
“Ciò che da valore alla guerra, è la vittoria. Quando la guerra dura
troppo a lungo, le armi si spuntano e il morale si deprime. Quando le
truppe assediano troppo a lungo le città, le loro forze si esauriscono in
fretta.”
Sun Tzu
5-6 giugno 2008
Progetto Sicurezza Accessi
9
Uso: Pubblico
Obiettivi
1. Orientare il flusso di richiesta delle abilitazione ai principi:
•Need to know
•Segregation of duties
2. Garantire al sistema di controllo la certezza di identificare gli attori del
processo di abilitazione integrandolo con le informazioni del sistema di
gestione del personale.
3. Rendere efficienti ed efficaci le attività tramite adeguati strumenti:
•Impiego del modello RBAC (Role-Based Access Control)
•Processo di abilitazione controllato tramite l’inserimento di vincoli
nel workflow
•Applicazione del principio SOD sia nel disegno dei processi/profili,
che in fase di abilitazione
•Uso di controlli a mitigazione del rischio di frodi/errori non
intenzionali se sussistono ragioni di carattere organizzativo che
indeboliscono l’applicazione del principio SOD
Per approfondimenti
5-6 giugno 2008
Progetto Sicurezza Accessi
10
Uso: Pubblico
Modello
IAM
Utenti
Profili
applicativi
Ruoli
Matrice ruoli
Unità
Organizzative
SOD
Transazioni
elementari
incompatibili
Attività di
business
Matrice attività
incompatibili
5-6 giugno 2008
Progetto Sicurezza Accessi
11
Uso: Pubblico
Calcolo SOD
Attività
incompatibili
A1
A1
A2
A3
X
A2
X
A3
Trans.
incomp.
T1
T1
T2
T2
T3
X
Attività
Trans.
Trans.
Ruolo
A1
T1
T1
R1
A2
T2
T2
R2
A3
T3
T3
R3
R1
R2
R3
Ruoli
incomp.
R1
X
R2
T3
X
X
R3
Per approfondimenti
5-6 giugno 2008
Progetto Sicurezza Accessi
12
Uso: Pubblico
Controllo SOD nella richiesta di abilitazione
Ruoli già associati a utente A
R1
R2
R4
Nuova richiesta
ruoli per utente A
Elenco ruoli
incompatibili
R5
R1
R5
R6
R2
R5
Matrice ruoli
incompatibili
R1
R2
X
R2
X
X
Responsabilità
sulle risorse
R5
R1
R5
Escalation
X
Per approfondimenti
5-6 giugno 2008
Progetto Sicurezza Accessi
13
Uso: Pubblico
Esempio di calcolo
Attività
incompatibili
A1
A1
A2
An
X
A2
Transazioni
T1
Incompatibili
X
An
T1
T2
Attività
Transazioni
A1
T1
A2
T2
An
Tn
5-6 giugno 2008
T2
Progetto Sicurezza Accessi
X
X
Tn
14
Tn
Uso: Pubblico
Sistema
Proprietario
informazioni
User
Manager
Referente
Abilitazioni
IAM
Applicazioni
Front-end
G.In.Ev.R.A.
G.In.Ev.R.A.
Identità
SAP HR
Connettori
Back-end
SAP HR
Utenti
Esterni
SAP R3
Motore
Motore gestione
gestione
flussi
flussi
…
…
Motore
Motore gestione
gestione
incompatibilità
incompatibilità
…
…
Amministratore
di sistema
Per approfondimenti
5-6 giugno 2008
Progetto Sicurezza Accessi
15
Uso: Pubblico
Connettori
I connettori sono bi-direzionali e devono garantire l’allineamento tra IAM
e le applicazioni:
• Aggiunta di utenti o abilitazioni (associazione utente-profilo) da IAM
all’applicazione
• Aggiunta di utenti o abilitazioni dall’applicazione a IAM. L’informazione
si deve abbinare con una richiesta di abilitazione, altrimenti si innesca
il trattamento dell’eccezione
Tramite i connettori trovano attuazione automatica alcune regole basate
su eventi avvenuti nel sistema di gestione del personale. Ad esempio le
seguenti:
• Rimozione di abilitazioni a seguito di cessazione
• Attivazione di abilitazioni standard a seguito di assunzioni
• Modifiche di abilitazioni a seguito di trasferimenti
Per approfondimenti
5-6 giugno 2008
Progetto Sicurezza Accessi
16
Uso: Pubblico
Organizzazione
Il governo del progetto ha richiesto una collaborazione stretta, paritaria
ed a più livelli, di vari enti aziendali:
• Security
• Audit
• Organizzazione
• Amministrazione
• ICT
• Linee operative
La parte più operativa si è svolta in una serie di sottoprogetti paralleli,
affidati alla responsabilità delle linee operative con l’obiettivo di integrare
in IAM il sistema di proprietà della linea.
La presenza sul campo della funzione Audit ha aggiunto subito
concretezza ed efficacia alle decisioni di progetto.
Per approfondimenti
5-6 giugno 2008
Progetto Sicurezza Accessi
17
Uso: Pubblico
Reticolo del progetto elementare
Adeguamento
Adeguamento
applicazione
applicazione
Adeguamento
Adeguamento
IAM
IAM
Pianificazione
Pianificazione
Kick-off
Riconciliazione
Riconciliazione
delle
delle identità
identità
Analisi
Analisi
Organizzativa
Organizzativa
Change
Change
Management
Management
Controllo
Controllo del
del progetto
progetto
Per approfondimenti
5-6 giugno 2008
Progetto Sicurezza Accessi
18
Go-live
Uso: Pubblico
Analisi SOD sui ruoli
Proprietari delle Informazioni coinvolti
81
Processi SOX relevant
43
Sistemi a supporto dei processi SOX relevant
91
Voci di analisi SAP (abbinamenti transazioni\attività)
692.788
Voci di analisi non SAP (abbinamenti ruoli\attività)
9.319
Voci di segregazione (abbinamenti ruoli\unità organizzative)
131.333
1519
13%
Ruoli leciti
Ruoli illeciti
9961
87%
Totale ruoli gestiti = 11.180
5-6 giugno 2008
Progetto Sicurezza Accessi
19
Uso: Pubblico
Informazioni gestite da IAM
Richieste User Manager
Richieste Referenti
04
-m
a
22 g
-m
ag
05
-g
iu
15
-g
iu
07
-lu
g
13
-lu
01 g
-a
go
28
-a
go
12
-s
et
27
-s
et
16
-o
t
06 t
-n
ov
22
-n
ov
13
-d
i
te c
rm
in
e
2400
2200
2000
1800
1600
1400
1200
1000
800
600
400
200
0
5-6 giugno 2008
Progetto Sicurezza Accessi
20
Uso: Pubblico
I fattori critici
“Gestire molti è come gestire pochi: basta curare l’organizzazione.
Controllare molti è come controllare pochi. È solo una questione di
addestramento e di segnalazioni.”
Sun Tzu
5-6 giugno 2008
Progetto Sicurezza Accessi
21
Uso: Pubblico
Punti di forza
• Analisi basata sulle transazioni elementari
• Analisi SOD automatica e trasversale a tutti i sistemi
• Collegamento diretto tra i repository delle identità e IAM: gestione a
360° del singolo dipendente
• Utilizzo di connettori bi-direzionali per garantire l’allineamento tra IAM
e le applicazioni
5-6 giugno 2008
Progetto Sicurezza Accessi
22
Uso: Pubblico
Linee di azione
Organizzativa
• Definizione di una procedura interna
» Disegno del workflow
» Individuazione degli attori
» Controlli specifici (sul flusso) e di monitoraggio (sui compiti)
• Coinvolgimento di tutti gli sponsor
• Formazione
Tecnica
• Realizzazione del modulo IAM
• Realizzazione del motore di calcolo SOD
5-6 giugno 2008
Progetto Sicurezza Accessi
23
Uso: Pubblico
Elementi critici
Cambio di mentalità nell’azienda
• Definizione profili
• Politiche di assegnazione dei profili
• Adeguamento dell’organizzazione e utilizzo della nuova flessibilità
Numerosità delle risorse umane coinvolte
• Formazione degli attori, in gran parte collocati in posizioni di alto
livello
• Definizione di politiche
• Bonifica delle incongruenze
Numerosità dei sistemi da connettere
• Individuazione delle specificità delle singole applicazioni e
realizzazione di soluzioni ad hoc
• Attivazione di connettori
5-6 giugno 2008
Progetto Sicurezza Accessi
24
Uso: Pubblico
Elementi di rischio
Il principale rischio è stato l’interferenza con i processi di business
• Le attività di progetto potevano interrompere altre azioni ugualmente
strategiche per l’azienda
5-6 giugno 2008
Progetto Sicurezza Accessi
25
Uso: Pubblico
L’esperienza
Gli investimenti sulle risorse umane sono indispensabili, ma non bastano
mai
• Le azioni per rafforzare il committment sono state necessarie per
tutta la durata del progetto ed hanno coinvolto i livelli più alti
• La formazione, in molti casi, deve essere ripetuta perché è difficile
trasmettere la visione completa del cambiamento. Inoltre essa deve
essere mirata e specializzata a seconda dei diversi destinatari
• La comunicazione dei risultati “in progress” è servita di stimolo per le
azioni ancora in corso
Le attività IT sono numerose e debbono essere tempestive
• Possono essere eseguite in anticipo: è un’opportunità da sfruttare
• Le persone del business danno per scontato che “la macchina”
funzioni. Non bisogna deluderle perché altrimenti si distraggono
5-6 giugno 2008
Progetto Sicurezza Accessi
26
Uso: Pubblico
Grazie
Umberto Isnardi
[email protected]
Enel
www.enel.it
5-6 giugno 2008
Progetto Sicurezza Accessi
27
Uso: Pubblico
Allegati
5-6 giugno 2008
Progetto Sicurezza Accessi
28
Uso: Pubblico
Definizioni (1/2)
Attività: si tratta delle sole attività rilevanti ai fini SOA cioè quelle la cui
sovrapposizione su una singola persona costituisce un “rischio in relazione ai
potenziali errori intenzionali nell’informativa di bilancio”.
Sistema Target: piattaforma informatica fisicamente collegata al sistema centrale
IAM attraverso uno o più connettori (ad esempio Active Directory, SAP R/3,
Hyperion, eccetera).
Applicazione: rappresentazione logica del target o di una parte di esso sul sistema
centrale.
Transazioni o Funzionalità: si tratta di funzionalità del medesimo sistema
informatico, le quali debbono essere trattate come un tutto unico dal punto di vista
software.
Profilo: si tratta di raggruppamenti di funzionalità del medesimo sistema
informatico, le quali debbono essere trattate come un tutto unico in fase di
abilitazione. In IAM sono rappresentati come coppia Applicazione\Funzionalità
Ruolo: si tratta di raggruppamenti di profili appartenenti a diversi sistemi
informatici, ma che sono assegnabili ad un unico soggetto all’interno del processo
abilitativo gestito in IAM. La definizione del ruolo avviene nel solo ambito
informatico. Nel sistema IAM ad un utente possono essere assegnati uno o più Ruoli.
5-6 giugno 2008
Progetto Sicurezza Accessi
29
Uso: Pubblico
Definizioni (2/2)
Utente: si tratta di un soggetto, interno od esterno all’azienda, che esegue delle
attività. Può essere abilitato a determinate funzionalità dei sistemi informatici.
Abilitazione o Autorizzazione: si tratta della capacità di un soggetto di far
eseguire ad un sistema informatico certe funzionalità. Nel modello della soluzione è
una relazione tra un utente ed un ruolo.
Unità Organizzativa: è un raggruppamento di utenti all’interno dell’azienda.
Disponibilità Ruoli su Base unità organizzativa: un Ruolo, per essere assegnato
ad un Utente appartenente ad una unità organizzativa, deve essere stato dichiarato
“assegnabile” a quella unità
Transazioni, profili o ruoli illeciti: si intendono elementi che, da soli, abilitano ad
eseguire almeno due attività tra loro incompatibili.
Transazioni, profili o ruoli incompatibili: si intendono elementi che, presi da soli
sono leciti, ma insieme abilitano ad eseguire almeno due attività tra loro
incompatibili.
Delega: un utente delegante può delegare uno o più ruoli, a lui assegnati, ad un
altro utente chiamato delegato; i ruoli posseduti da un utente in delega sono
SEMPRE temporanei, ma possono essere rinnovati.
Profilo Autorizzativo di un Utente: insieme dei Ruoli posseduti da un utente ad
una certa data.
5-6 giugno 2008
Progetto Sicurezza Accessi
30
Uso: Pubblico
Riferimenti normativi – Legge 196/03
TITOLO IV - SOGGETTI CHE EFFETTUANO IL TRATTAMENTO
Art. 28 (Titolare del trattamento)
1.Quando il trattamento è effettuato da una persona giuridica, da una pubblica
amministrazione o da un qualsiasi altro ente, associazione od organismo,
titolare del trattamento è l'entità nel suo complesso o l'unità od organismo
periferico che esercita un potere decisionale del tutto autonomo sulle finalità e
sulle modalità del trattamento, ivi compreso il profilo della sicurezza.
Art. 29 (Responsabile del trattamento)
1.Il responsabile è designato dal titolare facoltativamente.
2.Se designato, il responsabile è individuato tra soggetti che per esperienza,
capacità ed affidabilità forniscano idonea garanzia del pieno rispetto delle
vigenti disposizioni in materia di trattamento, ivi compreso il profilo relativo
alla sicurezza.
3.Ove necessario per esigenze organizzative, possono essere designati
responsabili più soggetti, anche mediante suddivisione di compiti.
4.I compiti affidati al responsabile sono analiticamente specificati per iscritto
dal titolare.
5.Il responsabile effettua il trattamento attenendosi alle istruzioni impartite dal
titolare il quale, anche tramite verifiche periodiche, vigila sulla puntuale
osservanza delle disposizioni di cui al comma 2 e delle proprie istruzioni.
5-6 giugno 2008
Progetto Sicurezza Accessi
31
Uso: Pubblico
Riferimenti normativi – Legge 196/03
Art. 30 (Incaricati del trattamento)
1.Le operazioni di trattamento possono essere effettuate solo da
incaricati che operano sotto la diretta autorità del titolare o del
responsabile, attenendosi alle istruzioni impartite.
2.La designazione è effettuata per iscritto e individua puntualmente
l'ambito del trattamento consentito. Si considera tale anche la
documentata preposizione della persona fisica ad una unità per la
quale è individuato, per iscritto, l'ambito del trattamento consentito
agli addetti all'unità medesima.
Titolo V - SICUREZZA DEI DATI E DEI SISTEMI
CAPO II - MISURE MINIME DI SICUREZZA
Art. 33 (Misure minime)
1.Nel quadro dei più generali obblighi di sicurezza di cui all'articolo
31, o previsti da speciali disposizioni, i titolari del trattamento sono
comunque tenuti ad adottare le misure minime individuate nel
presente capo o ai sensi dell'articolo 58, comma 3, volte ad
assicurare un livello minimo di protezione dei dati personali.
5-6 giugno 2008
Progetto Sicurezza Accessi
32
Uso: Pubblico
Riferimenti normativi – Legge 196/03
Art. 34 (Trattamenti con strumenti elettronici)
1. Il trattamento di dati personali effettuato con strumenti elettronici è consentito
solo se sono adottate, nei modi previsti dal disciplinare tecnico contenuto
nell'allegato B, le seguenti misure minime:
a)autenticazione informatica;
b)adozione di procedure di gestione delle credenziali di autenticazione;
c)utilizzazione di un sistema di autorizzazione;
d)aggiornamento periodico dell'individuazione dell'ambito del trattamento
consentito ai singoli incaricati e addetti alla gestione o alla manutenzione degli
strumenti elettronici;
e)protezione degli strumenti elettronici e dei dati rispetto a trattamenti illeciti
di dati, ad accessi non consentiti e a determinati programmi informatici;
f)adozione di procedure per la custodia di copie di sicurezza, il ripristino della
disponibilità dei dati e dei sistemi;
g)tenuta di un aggiornato documento programmatico sulla sicurezza;
h)adozione di tecniche di cifratura o di codici identificativi per determinati
trattamenti di dati idonei a rivelare lo stato di salute o la vita sessuale
effettuati da organismi sanitari.
5-6 giugno 2008
Progetto Sicurezza Accessi
33
Uso: Pubblico
Riferimenti normativi – Legge 262/05
Capo III - Sezione V-bis
Redazione dei documenti contabili societari
Art. 154-bis. - (Dirigente preposto alla redazione dei documenti
contabili societari).
1.Lo statuto prevede le modalità di nomina di un dirigente preposto
alla redazione dei documenti contabili societari, previo parere
obbligatorio dell’organo di controllo.
2.Gli atti e le comunicazioni della società previste dalla legge o diffuse
al mercato, contenenti informazioni e dati sulla situazione economica,
patrimoniale o finanziaria della stessa società, sono accompagnati da
una dichiarazione scritta del direttore generale e del dirigente
preposto alla redazione dei documenti contabili societari, che ne
attestano la corrispondenza al vero.
3.Il dirigente preposto alla redazione dei documenti contabili societari
predispone adeguate procedure amministrative e contabili per la
predisposizione del bilancio di esercizio e, ove previsto, del bilancio
consolidato nonché di ogni altra comunicazione di carattere
finanziario.
5-6 giugno 2008
Progetto Sicurezza Accessi
34
Uso: Pubblico
Riferimenti normativi – Legge 262/05
4.Al dirigente preposto alla redazione dei documenti contabili
societari devono essere conferiti adeguati poteri e mezzi per
l’esercizio dei compiti attribuiti ai sensi del presente articolo.
5.Gli organi amministrativi delegati e il dirigente preposto alla
redazione dei documenti contabili societari attestano con apposita
relazione, allegata al bilancio di esercizio e, ove previsto, al bilancio
consolidato, l’adeguatezza e l’effettiva applicazione delle procedure
di cui al comma 3 nel corso dell’esercizio cui si riferisce il bilancio,
nonché la corrispondenza del bilancio alle risultanze dei libri e delle
scritture contabili. L’attestazione è resa secondo il modello stabilito
con regolamento dalla CONSOB.
6.Le disposizioni che regolano la responsabilità degli amministratori
si applicano anche ai dirigenti preposti alla redazione dei documenti
contabili societari, in relazione ai compiti loro spettanti, salve le
azioni esercitabili in base al rapporto di lavoro con la società».
5-6 giugno 2008
Progetto Sicurezza Accessi
35
Uso: Pubblico
Titolare dell’abilitazione
È il dipendente o l’eventuale collaboratore esterno, al quale viene
consentito l’utilizzo di un sistema/applicazione informatica in relazione
alle attività assegnate o al rapporto di collaborazione in essere
Ha l’obbligo di segnalare al proprio responsabile ogni irregolarità
riscontrata nelle proprie abilitazioni, con particolar riguardo alle
abilitazioni che dovessero risultare a lui attribuite senza giustificato
motivo
5-6 giugno 2008
Progetto Sicurezza Accessi
36
Uso: Pubblico
User Manager
È il Responsabile di Unità Organizzativa
Individua, in relazione alle attività affidate e anche nel rispetto del
principio della segregation of duty, le esigenze di accesso ai sistemi ed ai
dati per i propri collaboratori e per i soggetti esterni che prestano la loro
attività sulla base di contratti gestiti nell’ambito della sua unità.
Incarica uno o più Referenti alle Abilitazioni con il compito di gestire il
flusso delle richieste di abilitazioni attinenti alla sua unità
5-6 giugno 2008
Progetto Sicurezza Accessi
37
Uso: Pubblico
Referente alle Abilitazioni
E’ la persona incaricata da uno o più User Manager per gestire il flusso
delle richieste di abilitazione per una o più unità Organizzative.
Verifica la completezza e la correttezza della richiesta ricevute dallo/dagli
User Manager di competenza e, ove necessario, la conformità alle policy
Richiede, nel caso di abilitazioni applicative non appartenenti a categorie
preventivamente autorizzate, l’approvazione al Proprietario delle
Informazioni competente
Richiede l’autorizzazione alla Security, nel caso di abilitazione “sensibile”
Richiede, a positiva conclusione delle precedenti verifiche, l’abilitazione
all’operatore competente
Riceve conferma dell’avvenuta abilitazione e trasmettere al titolare le
opportune indicazioni
5-6 giugno 2008
Progetto Sicurezza Accessi
38
Uso: Pubblico
Proprietario delle Informazioni
E’ il responsabile di una determinata applicazione per la quale assicura
l'integrità e la riservatezza dei dati, nonché l'uso degli stessi
coerentemente con le finalità per le quali i dati sono raccolti e detenuti,
conformemente con le norme e i regolamenti vigenti.
Cura, nel rispetto del principio della “segregation of duties”, la
definizione e periodica manutenzione delle politiche di accesso alle
applicazioni di competenza, assicurando la loro aderenza ai mutamenti
dell’organizzazione aziendale
Cura, nel rispetto del principio del "need-to-know”, l'appropriata
attribuzione dei profili autorizzativi agli utenti, in base alle necessità di
servizio formulate dagli User Manager
5-6 giugno 2008
Progetto Sicurezza Accessi
39
Uso: Pubblico
Operatore alle Abilitazioni
E’ la persona incaricata di attivare sui sistemi le abilitazioni degli utenti a
fronte di richieste inviate solo dai Referenti alle Abilitazioni designati.
È responsabile di:
• dare conferma dell’avvenuta abilitazione a chi ha formulato la
richiesta;
• tenere traccia di ogni richiesta gestita, con evidenza di colui che le ha
originate;
• collaborare con le diverse figure aziendali coinvolte nel processo della
gestione delle abilitazioni.
5-6 giugno 2008
Progetto Sicurezza Accessi
40
Uso: Pubblico
Gestione incompatibilità
Il modello di calcolo usa delle semplici tabelle per rappresentare i concetti
da trattare.
L’algoritmo permette di trasformare le informazioni di ingresso, costruite
con il linguaggio dei processi aziendali, in oggetti che i sistemi informatici
possono associare agli utenti per consentirgli di usare il sistema.
La matrice dei ruoli incompatibili è usata nel workflow delle abilitazioni
per determinare se è necessario effettuare escalation
I valori di incompatibilità sono: High, Medium
5-6 giugno 2008
Progetto Sicurezza Accessi
41
Uso: Pubblico
Workflow abilitazioni
User manager
A
Invio
richiesta
Referente alle abilitazioni
B
Richiesta SI
completa?
Resp User
Manager
Funzione ICT
C
E
Ruoli
compatibili?.
SI
Security
Proprietario delle
informazioni
F
Tecnica &
Budget OK?
Operatore alle
abilitazioni
G
SI
SI
Corretta OK?
SI
Sensibile OK?
NO
NO
NO
NO
NO
H
SI
D
Richiesta
viene
modificata?
NO
Effettuazione
abilitazione e
archiviazione
richiesta
DB
Accetto
incompatibilità?
D
SI
Proposta
controllo
compensativo
NO
Comunicazione
User manager
H
H
Invia al titolare
le opportune
informazioni
5-6 giugno 2008
Progetto Sicurezza Accessi
42
Notifica
avvenuta
abilitazione
Uso: Pubblico
Workflow abilitazioni
A. Lo User Manager richiede al Referente alle Abilitazioni il rilascio dell’abilitazione per il titolare
B. Il Referente alle Abilitazioni verifica la completezza della richiesta e, secondo il tipo coinvolge
nella verifica, gli attori “C”, “D”, “E”, “F” ed eventualmente anche la Funzione del PO
C. Qualora l’aggiunta dell’abilitazione generi un’incompatibilità, il referente alle abilitazioni
effettua escalation chiedendo ulteriore conferma allo User Manager.
D. Nel caso di incompatibilità lo User manager può annullare la richiesta, o ribadirla e così
indirizzarla al”Resp User Manager” che è incaricato di approvare o rifiutare la richiesta.
E. La funzione ICT valuta la correttezza tecnica, nonché, qualora le procedure divisionali lo
prevedano, la conformità alle policy/architetture e la copertura del budget.
F. Proprietario delle Informazioni competente è coinvolto nel caso in cui non coincida con lo
User Manager richiedente
G. L’autorizzazione dalla Security è necessaria nel caso di abilitazione “sensibili”
H. A conclusione positiva e documentata di tutte le precedenti verifiche, il Referente alle
abilitazioni, trasmette la richiesta all’Operatore alle Abilitazioni competente. Se una delle
verifiche dà esito negativo, il referente alle abilitazioni lo comunica allo User Manger
richiedente. L’Operatore alle Abilitazioni, effettuata l’abilitazione, tiene traccia delle
operazioni svolte e né dà riscontro al Referente alle Abilitazioni il quale, a sua volta,
trasmette al titolare le opportune indicazioni.
5-6 giugno 2008
Progetto Sicurezza Accessi
43
Uso: Pubblico
Tipologie di abilitazione
Tipologia
Tipologia
Standard
Standard
Criteri
Criteri di
di Assegnazione
Assegnazione
Abilitazioni
Abilitazioni ritenute
ritenute essenziali
essenziali per
per ii dipendenti
dipendenti in
in virtù
virtù
dell’appartenenza
dell’appartenenza ad
ad una
una determinata
determinata unità
unità organizzativa
organizzativa ed
ed aa
prescindere
prescindere dalle
dalle specifiche
specifiche mansioni
mansioni affidate
affidate (ad
(ad es.
es. accesso
accesso
rete
rete Windows,
Windows, posta
posta elettronica,
elettronica, SAP
SAP Time
Time &
& Travel
Travel
Management
Management ).
).
Abilitazioni
Abilitazioni rilasciate
rilasciate ai
ai singoli
singoli dipendenti
dipendenti in
in virtù
virtù delle
delle
specifiche
specifiche attività
attività ad
ad essi
essi affidate.
affidate. Si
Si distinguono
distinguono in
in
Non
Non
Standard
Standard
Infrastrutturali:
Infrastrutturali: sono
sono quelle
quelle relative
relative aa particolari
particolari servizi
servizi di
di
accesso
accesso ed
ed utilizzo
utilizzo del
del sistema
sistema informativo
informativo aziendale
aziendale (ad
(ad es.
es.
accesso
accesso ad
ad Internet,
Internet, certificati
certificati digitali,
digitali, Remote
Remote Access
Access Server,
Server,
Outlook
Outlook Web
Web Access
Access Internet,
Internet, Virtual
Virtual Private
Private Network)
Network)
Applicative:
Applicative: sono
sono quelle
quelle relative
relative all’accesso
all’accesso aa
procedure
procedure informatiche,
informatiche, applicazioni,
applicazioni, data
data base
base ee aree
aree
es.
SAP,
eccetera).
es. SAP, eccetera).
singole
singole
dati
dati (ad
(ad
Automaticamente
Automaticamente concesse
concesse
allorché
allorché ilil dipendente
dipendente
prende
prende per
per la
la prima
prima volta
volta
servizio
servizio presso
presso una
una
specifica
specifica unità
unità
Concesse
Concesse al
al dipendente
dipendente al
al
presentarsi
presentarsi di
di specifiche
specifiche
esigenze
esigenze di
di accesso
accesso aa
dati/sistemi
dati/sistemi connesse
connesse alle
alle
mansioni/attività
mansioni/attività affidate
affidate ee
nel
nel rispetto
rispetto dei
dei principi
principi di
di
Segregation
Segregation of
of duties
duties
Con
Con riferimento
riferimento agli
agli esterni,
esterni, siano
siano essi
essi collaboratori
collaboratori aa tempo
tempo determinato
determinato (stagisti,
(stagisti, somministrati,
somministrati,
lavoratori
lavoratori aa progetto)
progetto) oo dipendenti
dipendenti da
da altre
altre aziende
aziende che
che devono
devono accedere
accedere al
al sistema
sistema informativo
informativo dell’Enel
dell’Enel
nel
nel quadro
quadro di
di un
un contratto
contratto di
di fornitura
fornitura di
di servizi,
servizi, tutte
tutte le
le abilitazioni
abilitazioni sono
sono considerate
considerate non
non standard.
standard.
5-6 giugno 2008
Progetto Sicurezza Accessi
44
Uso: Pubblico
La componenti front-end di IAM
GINEVRA (Gestione INtegrata EVasione Richieste Abilitazione)
• Realizza il workflow delle richieste di abilitazione
• Gestisce l’insieme di tutti i Processi aziendali e le relative attività di
Business necessarie per l’espletamento di ogni specifico processo
• Gestisce la matrice di incompatibilità delle attività
• Fornisce un’interfaccia per i controlli da parte degli attori della
procedura di gestione delle abilitazioni (User Manager, Referenti alle
Abilitazioni, Proprietari delle Informazioni, eccetera)
5-6 giugno 2008
Progetto Sicurezza Accessi
45
Uso: Pubblico
Le componenti back-end di IAM:
Motore di gestione flussi (Profile Manager)
• Interfaccia i sistemi source (repository di identità)
• Esegue gli “ordini” impartiti da GINEVRA verso i sistemi target
• Esegue regole automatiche preimpostate
• Si preoccupa della memorizzazione dei profili, della tracciatura dei
processi abilitativi e della generazione della reportistica
Motore di calcolo delle incompatibilità SOD (RPD - Role Policy Definition)
• Calcola le matrici di incompatibilità delle transazioni e dei ruoli
• Manda in escalation le richieste che generano conflitti SOD
5-6 giugno 2008
Progetto Sicurezza Accessi
46
Uso: Pubblico
GINEVRA
User Manager
Referente
Abilitazioni
Proprietario delle Informazioni (PI)
Responsabile Personale e Organizzazione (PO)
Referente Corporate Security (CS)
Referente Demand & Delivery (DD)
Operatore Abilitazioni
GINEVRA
Flusso di richiesta delle abilitazioni
• Richiesta di abilitazione (testo libero)
• Formalizzazione / autorizzazione / rifiuto della richiesta
• Visualizzazione stato della richiesta
• Visualizzazione unitaria dei ruoli attribuiti ad un utente
• Consultazione reportistica
5-6 giugno 2008
Progetto Sicurezza Accessi
Interfaccia WEB
47
Uso: Pubblico
GINEVRA: Definizione attività / funzioni (1/2)
User
Manager
Referente
Abilitazioni
PI, PO, CS, DD
Generazione richiesta: inserimento e registrazione a sistema di una
particolare richiesta da parte dello User Manager; questa fase spesso si
concretizza nella compilazione di un campo puramente descrittivo per
descrivere la caratteristiche della richiesta (dati non strutturati)
Formalizzazione richiesta: i dati relativi alla richiesta vengono inseriti dal
Referente alle Abilitazioni all’interno di campi con valore e tipo definiti (dati
strutturati)
Autorizzazione della richiesta: in presenza di particolari sub-stati
autorizzativi inseriti a sistema, la richiesta può essere APPROVATAANNULLATA-SOSPESA da uno o più attori
5-6 giugno 2008
Progetto Sicurezza Accessi
48
Uso: Pubblico
GINEVRA: Definizione attività / funzioni (2/2)
Evasione richiesta: è normalmente lo step finale di un flusso di processo nel
sistema; l’Operatore alle Abilitazioni evade la richiesta attivandone gli effetti
Operatore
Abilitazioni
Proprietario
Informazioni
Autorizzazione aggiunta ruoli e applicazioni: blocco del flusso di
processo necessario quando un Ruolo non sia assegnabile per una certa
unità organizzativa od un’applicazione debba essere aggiunta in visibilità ad
una certa unità; tutte le operazioni di questo genere sono perfezionate
dall’Amministrato di Sistema IAM - Gestione
5-6 giugno 2008
Progetto Sicurezza Accessi
49
Uso: Pubblico
RPD - Funzionalità
Amministrazione: gestione delle anagrafiche con le classiche funzionalità di
Inserimento/Modifica/Cancellazione per :
• Processi di Business
• Attività di Business
• Matrice di incompatibilità
• Abbinamento Attività Profilo applicativo
Calcolo incompatibilità: produzione report e gestione escalation SOD su Ginevra
Report: visualizzazione elenchi prodotti dalla fase di calcolo
Utility - Export: permette di estrarre i report in formato excel
Configurazione:
• soglie di incompatibilità (Min % di attività accettata (0-100), Max livello di
incompatibilità accettato (Nessuno, Basso, Medio, Alto))
• flag di attivazione per Ginevra
• Bypass Calcolo Incompatibilità per unità organizzativa
• Bypass Calcolo Incompatibilità per Applicazione
5-6 giugno 2008
Progetto Sicurezza Accessi
50
Uso: Pubblico
RPD – Elenco Report
Profili applicativi illeciti: profili applicativi che, se assegnati anche singolarmente
ad un utente, consentono di eseguire attività tra loro incompatibili.
Profili applicativi incompatibili: coppie di profili che, se assegnati
contestualmente, consentono ad un utente di eseguire attività tra loro incompatibili.
Ruoli IAM illeciti: ruoli IAM che raggruppano profili illeciti o incompatibili.
Ruoli IAM incompatibili: coppie di ruoli singolarmente leciti ma che, se assegnati
contestualmente, consentono di eseguire attività incompatibili.
Utenti illeciti: utenti di sistema abilitati a ruoli illeciti o tra loro incompatibili,
ovvero che eseguono attività definite tra loro incompatibili.
Vengono calcolate anche le seguenti relazioni:
• Attività – Profilo applicativo: Elenco attività associate ad un profilo
applicativo
• Profili applicativi - Attività: Elenco dei profili associati ad una attività
• Profili applicativi orfani: Elenco dei profili che non sono stati analizzati dal
punto di vista SOD
5-6 giugno 2008
Progetto Sicurezza Accessi
51
Uso: Pubblico
RPD – Simulazione
Viene fornita una funzionalità che permette di gestire un ulteriore
ambiente identificato come Ambiente di Simulazione, dove effettuare a
priori modifiche sulla compatibilità tra le attività e relative associazioni
con i profili.
Nell’ambiente di Simulazione è possibile effettuare modifiche ed
effettuare analisi what-if su:
• ANAGRAFICA
• Processi di Business
• Attività di Business
• Associazione Profili-Attività
• CONFIGURAZIONE
• Min % di attività accettata (0-100)
• Max livello di incompatibilità accettato (Nessuno, Basso, Medio, Alto)
Non è possibile simulare variazioni di Bypass su Applicazioni e Unità
Organizzative.
5-6 giugno 2008
Progetto Sicurezza Accessi
52
Uso: Pubblico
Organigramma
Organizzazione
Security
Amministrazione
Audit
ICT
Linee di business
Steering Committee
Project Management Office
Comitato
tecnico
Change Management Office
Gruppo di lavoro
(1)
Gruppo di lavoro
(….)
Gruppo di lavoro
(n)
Linea di business
ICT
Amministrazione
5-6 giugno 2008
Progetto Sicurezza Accessi
53
Uso: Pubblico
Competenze e responsabilità
Roll Out dei vari sistemi
Preparazione
Steering
Committee
Fabbisogni
funzionali
Escalation 2^ livello
Comitato
tecnico
Requisiti
Escalation 1^ livello
PMO
Pianificazione
CMO
Gruppi di
lavoro
Controllo avanzamento
GO
Live
Erogazione formazione
Analisi SoD
Adeguamento IAM
Adeguamento applicazione
5-6 giugno 2008
Progetto Sicurezza Accessi
54
Supporto
Post avvio
Uso: Pubblico
Perimetro di integrazione
Il perimetro è stato limitato alle società italiane del gruppo Enel.
La funzione Amministrazione ha consegnato una lista prioritaria di sistemi
da integrare basata su considerazioni di materialità (impatto sul bilancio
consolidato).
La funzione ICT ha consegnato una lista di sistemi la cui integrazione ha
elevate caratteristiche di efficienza (elevata movimentazione delle
abilitazioni).
La selezione dei sistemi è avvenuta anche sulla base dell’aspettativa di
vita.
5-6 giugno 2008
Progetto Sicurezza Accessi
55
Uso: Pubblico
Master plan
2007
03
04
05
06
07
08
09
10
11
Completamento
Completamento
infrastruttura
infrastruttura
Analisi
Analisi Organizzative
Organizzative
Change
Change Management
Management
Adeguamenti
Adeguamenti applicazioni
applicazioni e
e IAM
IAM
Governo
Governo del
del programma
programma
5-6 giugno 2008
Progetto Sicurezza Accessi
56
12
Uso: Pubblico
I numeri del progetto
Proprietari delle Informazioni coinvolti
81
File prodotti
3125
Verbali redatti
133
Presentazioni effettuate
76
Piani di programma redatti
63
Deliverable censiti
323
Mail scambiate
5900
Dimensione repository
5,99 Gbyte
Dimensione casella di posta di progetto
1,3 Gbyte
Riunioni effettuate
144
5-6 giugno 2008
Progetto Sicurezza Accessi
57
Uso: Pubblico
Attività di integrazione
Pianificazione
• Definizione del piano di rilascio
Analisi organizzativa
• Analisi del profili applicativi in funzione delle attività che hanno impatto sul
bilancio
• Assegnazione dei profili alle strutture organizzative
Adeguamento applicazione
• Adeguamento applicativo
• Data cleansing / riconciliazione delle identità
Change Management
• Identificazione e formalizzazione dei ruoli e dei flussi autorizzativi
• Formazione degli attori
Riconciliazione delle identità
• Soluzione delle discordanze tra l’analisi organizzativa ed i dati dell’applicazione
Adeguamento IAM
• Realizzazione del connettore tra IAM e l’applicazione
• Applicazione dei risultati dell’Analisi Organizzativa
• Applicazione dei risultati del Change Management
• Importazione dei dati dall’applicazione
5-6 giugno 2008
Progetto Sicurezza Accessi
58