la gestione dellidentità digitale...©natale prampolini aiea roma 3 -11-04 2 la gestione...
TRANSCRIPT
© Natale Prampolini AIEA Roma 3-11-04 1
La gestione dell’identità digitale:analisi, progettazione e privacy
IngIng.. NataleNatale PrampoliniPrampolini
Business & Technology AdviserBusiness & Technology Adviser
© Natale Prampolini AIEA Roma 3-11-04 2
La gestione dell’identità digitale:conclusioni
- E’ un grosso lavoro, faticoso e difficilmente evitabile
- Serve per sistemare le situazioni pregresse
- Aiuta a rispettare le normative
- Non esistono scorciatoie, nè prodotti che risolvono tutto
© Natale Prampolini AIEA Roma 3-11-04 3
L'identità digitale: questa presentazione
NON E’
• La presentazione di un prodotto
• La presentazione di una soluzione
• Una lista di Best practices: non bastano 45’
E’
• Il risultato di esperienze sul campo
• Complessa ed eterogenea come l’argomento che tratta
• Contiene concetti rielaborati da produttori, società di consulenza, letteratura ed esperti del settore, a volte in contrasto tra loro
• Una serie di spunti per evitare errori già compiuti da altri
© Natale Prampolini AIEA Roma 3-11-04 4
La gestione dell’identità digitale:dare il giusto accesso alla persona giusta al momento giusto
- Concetti base e definizioni
- Le fasi: Accesso, Identificazione, Autenticazione, Autorizzazione, Validazione e Sottoscrizione
- Riferimenti con Codice della Privacy (D.lgs. 196/03)
- Esempi per mercato
- Base dati: LDAP vs. RDBMS
- I prodotti commerciali, gli standard a supporto
- Come introdurre uno strato di Identità Digitale in un sistema informativo complesso
© Natale Prampolini AIEA Roma 3-11-04 5
L'identità digitale: analogie con il mondo reale
REALE
• Accesso fisico: portineria
• Identificazione: Nome e Cognome
• Autenticazione: documento
• Autorizzazione: decisione in base ai privilegi associati
• Privilegi: in base al profilo, ruolo, caratteristiche
DIGITALE
• Accesso informatico: Login
• Identificazione: User-id
• Autenticazione: PWD• Autenticazione forte:
Documento elettronico
• Autorizzazione: decisione in base ai privilegi associati
• Privilegi: in base al profilo, ruolo, caratteristiche
© Natale Prampolini AIEA Roma 3-11-04 6
Concetti dell'Identità (digitale)
AUTENTICAZIONE:Un livello di sicurezza
che garantisce lavalidità di una
rappresentazione dell'identità
? Govt issued (Drivers license, social security, Passport)
? Biometric (Fingerprint, Retinal Scan, DNA)
? Self-selected (PIN number, secret password)
CONCETTO DEFINIZIONE ESEMPIO
ATTRIBUTI:Dati, profili, preferenze di una persona (fisica o
giuridica) o di un dispositivo
? Personal consumer preferences (e.g., travel, entertainment, dining)
? Identity-specific histories (e.g., purchases, medical records, etc.)
? Device capabilities information (e.g., text-only, video, etc.)
IDENTITA’: Identificazione univoca di un elemento di un
gruppo (istanza di una classe) tramite i suoi
attributi
? Natale Prampolini detto Nani, nato a Roma il 23-11-1950, codice fiscale PRMNTL50S23H501A
© Natale Prampolini AIEA Roma 3-11-04 7
VALIDAZIONE:Conferma della volontà
da parte di un terzo rispetto alle due parti
del contratto
? Notaio per passaggi di proprietà,volture, successioni
CONCETTO DEFINIZIONE ESEMPIO
SOTTOSCRIZIONE:Manifestazione di
volontà, quindi un atto probatorio
? Firma autografa? Firma su assegni? Testamento? Contratti? Ricevuta di carta di credito
La possibilità di fornire servizi /
prodotti in dase adun'identitàautenticata
? Services based on attributes (e.g,. Travel, entertainment, dining)
? Transaction consummation? Gradient levels of service (e.g.,
based on employee level)
AUTORIZZAZIONE:
Concetti dell'Identità (digitale)
© Natale Prampolini AIEA Roma 3-11-04 8
Dalla parte dell’utente
• Multiple carte, di credito, di debito, di riconoscimento, tesserine magnetiche, ecc.
• Multipli login, con UserId e Pwd
Ogni volta che chiedete un’informazione, comprate su Internet, vi iscrivete ad un convegno vi chiedono: nome, cognome, indirizzo, telefono, fax, email, ecc.
(Comunque vi chiedono più dati di quanti strettamente necessari, e il codice sulla Privacy (196/03) sanziona questo comportamento, in quanto non conforme alla legge…)
© Natale Prampolini AIEA Roma 3-11-04 9
Sistemi di riconoscimento
© Natale Prampolini AIEA Roma 3-11-04 10
Dalla parte dell’amministratore di sistema
• Per ogni nuovo dipendente devo provvedere a:
h Tesserino per accessi e procedure del personaleh Desktop con UserId e Pwdh Account di mailh Accessi alle applicazioni generalih Accessi alle applicazioni specificheh Accesso da remoto/mobile?h Accessi da dispositivi non PC?h Niente altro?
• E se è un consulente / partner / temporaneo?• Unified User Management
• Provisioning, User Management, Deprovisioning
© Natale Prampolini AIEA Roma 3-11-04 11
• Il trattamento di dati personali effettuato con strumenti elettronici è consentitosolo 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.
Codice 196/03 “Privacy”Art. 34 - Trattamenti con strumenti elettronici
© Natale Prampolini AIEA Roma 3-11-04 12
• Sistema di autenticazione informatica
• 1. Il trattamento di dati personali con strumenti elettronici è consentito agli incaricati dotati di credenziali di autenticazione che consentano il superamento di una procedura di autenticazione relativa a uno specifico trattamento o a un insieme di trattamenti.
• 2. Le credenziali di autenticazione consistono in un codice per l’identificazione dell’incaricato associato a una parola chiave riservata conosciuta solamente dal medesimo oppure in un dispositivo di autenticazione in possesso e uso esclusivo dell’incaricato, eventualmente associato a un codice identificativo o a una parola chiave, oppure in una caratteristica biometrica dell’incaricato, eventualmente associata a un codice identificativo o a una parola chiave.
• 3. Ad ogni incaricato sono assegnate o associate individualmente una o più credenziali per l’autenticazione.
• 4. Con le istruzioni impartite agli incaricati è prescritto di adottare le necessarie cautele per assicurare la segretezza della componente riservata della credenziale e la diligente custodia dei dispositivi in possesso ed uso esclusivo dell’incaricato.
• 5. La parola chiave, quando è prevista dal sistema di autenticazione, è composta da almeno otto caratteri oppure, nel caso in cui lo strumento elettronico non lo permetta, da un numero di caratteri pari al massimo consentito; essa non contiene riferimenti agevolmente riconducibili all’incaricato ed è modificata da quest’ultimo al primo utilizzo e, successivamente, almeno ogni sei mesi. In caso di trattamento di dati sensibili e di dati giudiziari la parola chiave è modificata almeno ogni tre mesi.
Codice 196/03 “Privacy” Allegato Bdisciplinare tecnico in materia di misure minime di sicurezza
© Natale Prampolini AIEA Roma 3-11-04 13
• Sistema di autenticazione informatica (continua)
• 6. Il codice per l’identificazione, laddove utilizzato, non può essere assegnato ad altri incaricati, neppure in tempi diversi.
• 7. Le credenziali di autenticazione non utilizzate da almeno sei mesi sono disattivate, salvo quelle preventivamente autorizzate per soli scopi di gestione tecnica.
• 8. Le credenziali sono disattivate anche in caso di perdita della qualità che consente all’incaricato l’accesso ai dati personali.
• 9. Sono impartite istruzioni agli incaricati per non lasciare incustodito e accessibile lo strumento elettronico durante una sessione di trattamento.
• 10. Quando l’accesso ai dati e agli strumenti elettronici è consentito esclusivamente mediante uso della componente riservata della credenziale per l’autenticazione, sono impartite idonee e preventive disposizioni scritte volte a individuare chiaramente le modalità con le quali il titolare può assicurare la disponibilità di dati o strumenti elettronici in caso di prolungata assenza o impedimento dell’incaricato che renda indispensabile e indifferibile intervenire per esclusive necessità di operatività e di sicurezza del sistema. In tal caso la custodia delle copie delle credenziali èorganizzata garantendo la relativa segretezza e individuando preventivamente per iscritto i soggetti incaricati della loro custodia, i quali devono informare tempestivamente l’incaricato dell’intervento effettuato.
• 11. Le disposizioni sul sistema di autenticazione di cui ai precedenti punti e quelle sul sistema di autorizzazione non si applicano ai trattamenti dei dati personali destinati alla diffusione.
Codice 196/03 “Privacy” Allegato Bdisciplinare tecnico in materia di misure minime di sicurezza
© Natale Prampolini AIEA Roma 3-11-04 14
• Sistema di autorizzazione
• 12. Quando per gli incaricati sono individuati profili di autorizzazione di ambito diverso è utilizzato un• sistema di autorizzazione.• 13. I profili di autorizzazione, per ciascun incaricato o per classi omogenee di incaricati, sono
individuati e configurati anteriormente all’inizio del trattamento, in modo da limitare l’accesso ai soli dati necessari per effettuare le operazioni di trattamento.
• 14. Periodicamente, e comunque almeno annualmente, è verificata la sussistenza delle condizioni per la conservazione dei profili di autorizzazione.
• Altre misure di sicurezza
• 15. Nell’ambito dell’aggiornamento periodico con cadenza almeno annuale dell’individuazione dell’ambito del trattamento consentito ai singoli incaricati e addetti alla gestione o alla manutenzione degli strumenti elettronici, la lista degli incaricati può essere redatta anche per classi omogenee di incarico e dei relativi profili di autorizzazione.
Codice 196/03 “Privacy” Allegato Bdisciplinare tecnico in materia di misure minime di sicurezza
© Natale Prampolini AIEA Roma 3-11-04 15
Enterprise Identity Infrastructure
The demand for reusable identity information is high
h Applications and databases maintain accounts and customer records
h Security and regulatory compliance require identity information
• Directory services are just the starting point
h Enterprise identity architecture requires use of meta-directory, virtual directory, user administration, and federation products
• These are not plug-n-play components, however
h Architects must understand what each is used for and plan create an appropriate architecture
h Interoperability is not assured
• Use a combination of products and technologies to create a strong identity infrastructure
© Natale Prampolini AIEA Roma 3-11-04 16
Directories: Foundation for Identity
• Directories are still the best option for identity reuse
• Data model is designed for identity operations
h Good for rules/roles storage and calculation
h Managing relationships among entries
• Performance is optimized for identity
h LDAP provides straight-forward methods for using and describing information about groups, relationships, entry/attribute pairing
h Simple, dynamic replication for distribution and horizontal scale
• Lots of applications rely on LDAP
• Directories don’t deliver all the features, however
h LDAP directories are necessary but not sufficient for creating reusable identity infrastructure
h Architects need to think beyond the directory service àidentity service
© Natale Prampolini AIEA Roma 3-11-04 17
Directories: Foundation for Identity• Defining the identity services layer
Authentication Access management User management
Identity access layer
PKI / other /specialized
Web access mgmt. Provisioning Identity andpolicy admin.
Directory repositories Meta-directoryVirtual directory /federation
© Natale Prampolini AIEA Roma 3-11-04 18
Drafting an Architecture for Identity• Putting the pieces together
© Natale Prampolini AIEA Roma 3-11-04 19
Drafting an Architecture for Identity
• Identity infrastructure toolbox
• Access layer and proxy servicesh Including federation standards and systems
• Virtual directoryh Link accounts and retrieve data directly from sources
• Meta-directoriesh Link accounts and synchronize attributes
• Provisioning systemsh Manage accounts as a business process
• LDAP directory servicesh Profile storage, authentication, defining relationships
• Identity and policy administration tools
© Natale Prampolini AIEA Roma 3-11-04 20
Introduction
LDAPdirectories
Messag-ing
PBX / CTIVoIP
Identity-basedcompany access
Advanced businessinfrastructure
Basic businessinfra-structure
Enabling technology network/basic network infrastructure (network, servers, routers, OS, transport services)
Security/PKI
Manage-ment
Objectservices
Data-bases
Webservices
businessprocess
integrationMeta Directory services
Identit
ymana
gement
Acces
s/aut
horiza
tionAu
thentic
ation
Resourc
e pro
vision
ing
businessapplications
Process integration is just as important as the technology
Remote
employees
Legal/p
ublic
authoritie
s
EmployeesSuppliers
Partners
Customers
© Natale Prampolini AIEA Roma 3-11-04 21
Making it happen: products and vendors• Identity market vendor consolidation
MetamergeMetamerge
BaltimoreBaltimore
InnosoftInnosoft
PhaosPhaos
Business LayersBusiness Layers
IBMIBM
DASCOMDASCOMAccess360Access360
NetegrityNetegrity
WavesetWaveset
TruLogicaTruLogica
HPHP
Sun OracleOracle
NetScreenNetScreen
NeoterisNeoteris JuniperJuniper
© Natale Prampolini AIEA Roma 3-11-04 22
Making it happen: products and vendors
Vendors of identity infrastructure products
üütoolkitCalendra
ü & proxytoolkitSymlabs
üüin dev.Oblix
ü
ü
üKerberos
ü
üFederation
üOctetString
CalendraüüCritical Path
üüüNovell
üsomeRadiant
üembeddedüüSunüüüSiemens
üüüMaXwareüNetscapeHP
BizTalküüMicrosoftüüüIBM
üüüCAWorkflowVirtual-DirSynchDirectory
© Natale Prampolini AIEA Roma 3-11-04 23
Enterprise Identity Infrastructure
• Recommendations
• Create an architecture for identity servicesh Make use of the identity infrastructure tools now availableh Define an access layer that abstracts product-specificity from
internal developersh Include plans for management and administration of identity
servicesh Some pieces may not be needed
– Virtual directory, federation, and proxy are not always required at the identity service level
• Consider component integration during product selectionh How will pieces fit together to create a holistic solution?h Rely on a strategic / primary vendor with partnerships for missing
pieces
© Natale Prampolini AIEA Roma 3-11-04 24
Enterprise Identity Infrastructure
• Conclusion
• Identity services are mandatoryh Applications, infrastructure, and and regulations require accurate
identity information
• Directory services are necessary, but not sufficienth Several other products must be used in combination with directory
services to meet the requirements of the identity serviceh Architects need to plan the deployment, because the products
aren’t well integrated
• The identity service includes features fromh Directory, meta-directory, provisioning, directory proxy, virtual
directory, and administration productsh An access layer, which may require some custom development
© Natale Prampolini AIEA Roma 3-11-04 25
Introduction• Start small and build upon your experience
• Infrastructure services must leverage the preceding technologies
• Most organizations have at least developed their directory and underlying network and application infrastructures
• Identity infrastructures are the fastest growing area of the marketplace
• Federation is rapidly increasing (5-10% of the Global 2000)
Othertechnologies
Directory Identity Federation
95-100%70-80% 20-30% 5-10%
Organizational deployment
© Natale Prampolini AIEA Roma 3-11-04 26
Cost Savings
• Technologies: Directory services benefits (cont.)
© Natale Prampolini AIEA Roma 3-11-04 27
Linkage of Trust Domains
.com .com
.com.com
.com.com
.com .com
.com.com
.com.com.com .com
.com.com
.com.com
Bank ATMNetwork A
Bank ATMNetwork B
Bank ATMNetwork C
Bank AATM Card
Bank BATM Card
Bank CATM Card
Individual Accounts with Many Web Sites
.com
.com
.com
Bank AATM Card
Bank BATM Card
Bank CATM Card
Federated Accounts within Trust Domain
.com
.com
.com
.com
.com
.com
Bank ATMNetwork A
Bank ATMNetwork B
Bank ATMNetwork C
Identità FederataSoluzione Analoga alle reti ATM
Separate Cards with Each Bank
Linked Cards within Bank Networks
Seamless Access Across all Networks
© Natale Prampolini AIEA Roma 3-11-04 28
Examples of Trust Domains
Treasury Debt
EquityCommercialBanking
CreditClearingHouse
B2B – Financial Services
Suppliers Dealers
TransportAgencies
Manufacturers
FinancingFleet
B2B - Automotive
Car Rental
Hotel
PartnerAirlines
Airline
TrainCruiseLine
B2C – Travel Industry401k 3d Party
Providers
EmployeePurchase
Plans
DentalInsurance
Health Insurance
CompanyIntranet
B2E – EmployeeIntranet
© Natale Prampolini AIEA Roma 3-11-04 29
Esempio per le Assicurazioni: la Gestione Sinistri
• Nel ramo danni, in molti casi va valutato il danno.
• Il flusso di lavoro prevede:
• notizia del sinistro da parte del cliente all’agenzia e da questa all’assicurazione
• stima da parte dell’ispettore (dipendente dell’assicurazione)
• valutazione da parte del perito (consulente esterno)
• proposta da parte dell’ispettore
• accettazione dell’indennizzo da parte del cliente
• erogazione da parte dell’assicurazione
© Natale Prampolini AIEA Roma 3-11-04 30
Esempio di Telco Mobile
• Accesso
• via HTTP, punto fisso
• via telefono mobile
• via portale di un partner• Identità
• Se avete un telefono mobile, nota
• Se il telefono mobile è acceso, georeferenziato
• se via HTTP, come verificare verso il telefono mobile?
© Natale Prampolini AIEA Roma 3-11-04 31
Esempio di Telco Mobile
• Autenticazione
• via HTTP, userid e pwd
• via telefono mobile, implicita
• via partner portal: da richiedere
• Autorizzazione
• Verso i miei servizi: facile, basso rischio
• Verso i servizi del partner, non è un mio problema
• Verso i servizi del partne: rischio medio-alto
• Serve un'autorizzazione maggiore
© Natale Prampolini AIEA Roma 3-11-04 32
Il controllo accessi
• User Based: va bene solo per piccole organizzazioni, diventa velocemente troppo complesso da gestire
• Rule Based: va bene anche per grandi organizzazioni, ma bisogna definire tutte le regole, e verificarle ad ogni accesso
• Role Based: va bene solo per organizzazioni strutturate, con ruoli e processi ben definiti. Rappresenta, se ben progettato, un metodo molto efficiente.
© Natale Prampolini AIEA Roma 3-11-04 33
Enterprise Directory Server
• Fondamenti di progettazione
• Il DIT sta al directory come lo schema entità-relazione sta agliRDBMS
• Gli oggetti (object classes) stanno al Directory come lo schema relazionale sta agli RDBMS.
• Gli indici e gli atttributi stanno al Directory come all'RDBMS• L’LDAP sta al directory come lo SQL sta agli RDBMS
Problema di provisioningdei dati
Implementazione della fase di progettazione
© Natale Prampolini AIEA Roma 3-11-04 34
Protocollo LDAP – Functional model
Operazioni di interrogazione:
search, compare
Operazioni di Autenticazione e di Controllo
bind, unbind, abandon
Operazioni di modifica:
add, delete, modify, modify DN (rename)
LDAP definisce nove funzioni/azioni base:
© Natale Prampolini AIEA Roma 3-11-04 35
Gruppi Statici
• I gruppi statici hanno un attributo chiamato uniqueMember con un valore fissato al DN per ogni membro del gruppo
• Vanno bene per gruppi di piccole dimensioni
• Non scalano bene• Una modifica richiede la riscrittura dell'intera entry
• Molte operazioni di update se il DN cambia o se la entry viene rimossa
• Ogni entry deve essere letta dall'interfaccia di gestione
dn: cn=Baseball Fans,ou=Groups,dc=siroe,dc=comobjectClass: topobjectClass: groupofuniquenamescn: Baseball FansuniqueMember: uid=rwilson,ou=People,dc=siroe,dc=comuniqueMember: uid=scarter,ou=People,dc=siroe,dc=com
dn: cn=Baseball Fans,ou=Groups,dc=siroe,dc=comobjectClass: topobjectClass: groupofuniquenamescn: Baseball FansuniqueMember: uid=rwilson,ou=People,dc=siroe,dc=comuniqueMember: uid=scarter,ou=People,dc=siroe,dc=com
© Natale Prampolini AIEA Roma 3-11-04 36
Gruppi Dinamici
• Hanno un attributo chiamato memberURL, che, definendo le entry richiama una LDAP URL (una LDAP search)
• Le applicazioni devono compiere operazioni di read e searchutilizzando LDAP URL(s)
• Automaticamente valutate dal DS quando usati in ACI
• Scalano bene
dn: cn=Accounting Members,ou=Groups,dc=siroe,dc=comobjectClass: topobjectClass: groupofuniquenamesobjectClass: groupofurlscn: Accounting MembersmemberURL: ldap:///dc=siroe,dc=com??sub?(&(objectclass=person)(ou=Accounting))
dn: cn=Accounting Members,ou=Groups,dc=siroe,dc=comobjectClass: topobjectClass: groupofuniquenamesobjectClass: groupofurlscn: Accounting MembersmemberURL: ldap:///dc=siroe,dc=com??sub?(&(objectclass=person)(ou=Accounting))
© Natale Prampolini AIEA Roma 3-11-04 37
Roles
• I “roles” sono un superset dei gruppi
• Le performance dei “ roles” sono state ottimizzate nel DS
• Assieme alle permission definiscono l’RBAC
• “Managed Roles” – simili ai gruppi statici
• “Filtered Roles” – simili ai gruppi dinamici
• “Nested Roles” – possono contenere altri “roles”
• I “roles” sono essenziali per una amministrazione cost-effective
• Una terminologia inconsistente ed una carenza di standard riguardanti i “roles-based access control” (RBAC) rallenta i miglioramenti e complica iconfronti tra prodotti
© Natale Prampolini AIEA Roma 3-11-04 38
RBAC
elementi base• Gli utenti sono assegnati ai “roles”
• Le risorse hanno delle ”permissions” associate
• Le “permissions” per le risorse sono abbinate ai “roles”
• I “roles” permettono l'astrazione => efficienza, flessibilità, scalabilità
Users Roles Permissions Resources
© Natale Prampolini AIEA Roma 3-11-04 39
“Roles” ed RBAC
Le definizioni e la gestione devono essere top-down• I processi di Business devono guidare e controllare i processi
tecnologici
• Nella e-economy e' fondamentale un appropriato controllo
Business Process Layer
Role Admin Layer
Access Control Layer
Roles
AssignmentsTo roles ONLY
Jobs
© Natale Prampolini AIEA Roma 3-11-04 40
“Roles” ed RBAC Assegnazione dei ruoli
• Static: utilizza i gruppi, non scala, e' facile la delega, molte operazioni di update per spostamenti/terminations
• User: scala bene, difficile la delega, semplice la review degli user-role
• Dynamic: auto assegnazione, richiede ottimi processi e dati noncorrotti, utilizzato per provisioning ed accesso web
Static Assignment User AssignmentDynamic Assignment
JohnRoles:§ Manager§ EngineerAffiliation:§ EmployeeTitle:§ Engineering manager
Manager§ John§ Mary
Engineer§ John§ Bill
Employee§ Entries with
affiliation=‘Employee’
Groups
Manager§ Entries with ‘manager’
in their title
© Natale Prampolini AIEA Roma 3-11-04 41
“Roles” ed RBAC -Value Proposition
Administrazione piu' facile, veloce e sicura• Meno lavoro – amministratori ed utenti piu' produttivi
• Users + permissions, invece di users x permissions• L'amministratore degli utenti non deve conoscere i processi di
business• Aggiunta e rimozione di “roles” senza modifica degli accessi • Richiesto meno skill nella normale amministrazione
• Meno assegnazioni favoriscono meno errori
La semplificazione riduce i costi• Permette automazione e riutilizzo di lavori già svolto• Riduce il numero degli amministratori e dello skill richiesto
© Natale Prampolini AIEA Roma 3-11-04 42
“Roles” ed RBAC -Value Proposition
Facile scalabilità con la crescita• La gestione delle access control list (ACLs) non e'
scalabile
• Numero del rapporto users/permissions puo' crescerein maniera esponenziale e la gestione si complica
Miglior sicurezza• Separazione della gestione amministrativa
• Miglior monitoring ed auditing
© Natale Prampolini AIEA Roma 3-11-04 43
Possibili scenari di introduzione di un IdM
• Directory Server• Directory Opaco
• Enterprise Directory Server
• Identity Server• SSO (Web Single Sign On, Reduced Sign On)
• Federation
• Portal Server• Web Application
• Legacy Application
• Gestione centralizzata• Delega di amministrazione
• Gestione applicativa
© Natale Prampolini AIEA Roma 3-11-04 44
Directory Server
• Opaco• I prodotti di Identity Management prevedono la presenza di un
sistema di Directory Server.
• Tutti i prodotti hanno bisogno e usano un directory in modo nativo (mascheramento della Directory)
• Non è necessario prevedere attività sul Directory Server nel caso in cui la soluzione sia per SSO, o Unified user Management o Mail o Portal.
Nessuna attività prevista
© Natale Prampolini AIEA Roma 3-11-04 45
Enterprise Directory Server
• Base fondativa dello Unified User Management
• In che modo è organizzata la base di utenza del sistema (perorganizzazioni aziendali, per canali, organizzazione alfabetica etc..)
• Le applicazioni aziendali devono essere LDAP enabled• Esiste un sistema di provisioning aziendale • La creazione dei dati è integrata con i processi aziendali
Attività di progettazione delloschema (DIT) e degli oggetti
Workshop di introduzione alloUnified User Management
© Natale Prampolini AIEA Roma 3-11-04 46
Identity Management
• Esiste gia' un sistema di Directory?
• Se la risposta è no --> vedi le slides precedenti• Se la risposta è si: cosa si deve proteggere? Come? È necessario
un sistema di SSO? E' solo un problema di accesso o anche di presentazione? Se a questa domanda la risposta è: Presentazione vai alle soluzioni con Portal Server
• Siamo nel caso di WebApplication?
• Se la risposta è si: i servizi da proteggere sono identificabili condelle URI?
Linee guida di interoperabilià applicativaAnalisi applicazioni enterprise
© Natale Prampolini AIEA Roma 3-11-04 47
Identity Management• Lo sponsor del progetto puo' far leva sugli owner delle
applicazioni?• Se la risposta è no --> rischio altissimo• Se la risposta è si: si deve prevedere un tavolo di assessment
applicativo (con sviluppatori)
• E' possibile avere al tavolo di assessment anche il responsabile della sicurezza?
• Se la risposta è no: esiste una tabella che lega la criticità dei processi alla criticità dei dati?
• Se la risposta è si: ricordare che non si tratta di sicurezza perimetrale?
Specifiche
© Natale Prampolini AIEA Roma 3-11-04 48
Portal Server• E' possibile dividere le applicazioni in Web e Legacy?• Le applicazioni legacy prevedono un client apposito?
Esiste?• I contenuti sono tutti già collocati in azienda?
• Il sistema di Portal dovrà organizzare l'accesso alle applicazioni o anche fornire i meccanismi di visualizzazione dell'input e dell'output?
• L'autorizzazione funzionale rimane nelle applicazioni?
• Ci sono contenuti provenienti dall'esterno che vanno integrati?
© Natale Prampolini AIEA Roma 3-11-04 49
Portal Server
• Il sistema di Mail Enterprise prevede la presenza delle Mailsul server?
• L'eventuale client di Mail Corporate prevede la possibilità di avere piu' profili?
• Chi si fa carico della integrazione applicativa con il sistema di Portal?
• Il cliente è consapevole che deve modificare le applicazioni?
© Natale Prampolini AIEA Roma 3-11-04 50
Gestione User e Applicazioni
• La gestione utenti deve essere delegata?
• Ad Aziende del gruppo o in servizio di outsourcing?
• Che visibilità deve essere data dei dati dei singoli utenti?
• Le applicazioni devono essere integrate in un ambiente operativo esistente?
• Ci sono livelli di operatori diversi? (junior, senior)
• Con differenti livelli di responsabilità sulla suite?
© Natale Prampolini AIEA Roma 3-11-04 51
Gestione User e Applicazioni:SAP Portal (50 057 993s (02/08s))
© Natale Prampolini AIEA Roma 3-11-04 52
Gestione User e Applicazioni:Oracle Identity Management
• Oracle Indentity Management (OIM) è un’infrastruttura integrata per la gestione degli aspetti di sicurezza legati all’identificazione dell’utente.
• Gestione di un unico repository, LDAP v3 (Oracle Internet Directory)• Servizio di Autenticazione centralizzato Oracle Single SignOn Server• In più Oracle Directory Integration Platform (ODIP): al fine di ottenere un repository unico
degli utenti OID offre un insieme di API denominate Oracle Directory Integration Platform(ODIP) per garantire l’integrazione (master-slave e/o master-master) con altri repository
• OID• iPlanet Connector • Oracle HR Connector • Active Directory Connector
• OSSO• Web Server plug-in: Apache, Sun Web server, MS IIS• Application Server J2EE• IdM: Netegrity Siteminder ®, RSA ClearTrust, IBM Tivoli Access Manager• Login trasparente su Windows (Microsoft Kerberos• Supporto per i certificati e smartcard (Poste, Infocamere, CIE, CNS, Poste, BNL ecc)
© Natale Prampolini AIEA Roma 3-11-04 53
Gestione User e Applicazioni:Black Box
• Ho un’applicazione funzionante, ma non la posso modificare (!!!)h Non ho i sorgenti, è troppo complesso/difficile, scade la garanzia, il
fornitore non vuole modificarla, ecc.
• Posso inserire uno strato in mezzo?
• Posso mettere un automa che simuli il login da parte dell’utente?
• Posso canalizzarla in una Portlet di un Portale?
• Probabilmente ho risolto il SSO, forse anche il Provisioning• Il Deprovisioning rimane da automatizzare
© Natale Prampolini AIEA Roma 3-11-04 54
Linguaggi e standard:OASIS
• The Organization for the Advancement of Structured Information Standards
• www.oasis-open.org
• DSML: Directory Services Markup Language v2.0 December 18, 2001Approved as an OASIS Standard April 30,2002
• XACML: eXtensible Access Control Markup Language XACML 1.1 Specification Set (24 July 2003):
• XACML Profile for Role Based Access Control (RBAC): Committee Draft 01 (normative; 13 February 2004)
• SAML: Security Assertion Markup Language v1.1 August 2003
• WSS: Web Services Security v1.0 March 2004
© Natale Prampolini AIEA Roma 3-11-04 55
Linguaggi e standard:Liberty Alliance
• www.projectliberty.org
• Liberty Alliance ID-FF 1.2 Specifications:Liberty Identity Federation Framework
• Liberty Alliance ID-WSF 1.0 Specifications:Liberty Identity Web Services Framework
• Liberty Alliance ID-SIS 1.0 Specifications:Liberty ID-SIS Personal Profile Service
© Natale Prampolini AIEA Roma 3-11-04 56
Considerazioni finali
• Affidare la gestione dell'Identità Digitale ad un frameworkinfrastrutturale può aiutare a progettare e realizzare applicazioni dotate dei necessari gradi di sicurezza, riservatezza e semplicitàd'uso oggi richiesti.
• Utilizzare un framework di gestione dell'Identità Digitale può servire a concentrarsi sullo sviluppo della logica applicativa e realizzare moduli di funzioni che implementano servizi consistenti.
• E' necessario avere uno schema di progetto che evidenzi chiaramente le funzioni e i servizi richiesti al framework di gestione dell'Identità Digitale: solo in questo modo l'introduzione potrebbe avvenire con un impatto contenuto e con grande utilità nelle architetture attuali.
© Natale Prampolini AIEA Roma 3-11-04 57
L'identità digitale
NaniNani PrampoliniPrampolini
[email protected]@ordine.ingegneri.vi.it
www.www.prampoliniprampolini.net.net
Domande Domande ??