ARCHITETTURA DI NOVELL SECURELOGIN
Transcript
ARCHITETTURA DI NOVELL SECURELOGIN
Architettura di Novell SecureLogin ( estratto documentazione offerta tecnica ) La soluzione proposta è quella di Novell, basata su Novell SecureLogin 7.0 SP1. Novell SecureLogin fornisce strumenti di autenticazione e automatismi di single sign-on verso differenti reti ed applicazioni all’interno di una Organizzazione. Una delle prerogative principali del prodotto è quella di poter essere utilizzato come unico punto di ingresso alla rete aziendale ed alle sue risorse.Ogni qualvolta l’utente (Workstation) cerchi di accedere ad una applicazione (applicazioni Win32, Web, o Java, applicazioni pubblicate via Citrix Terminal Server, sessioni di emulatore terminale, etc.), il SecureLogin Client intercetta l’evento, effettua il recupero delle credenziali utente ed esegue l’autenticazione sul sistema target per conto dell’utente. SecureLogin memorizza le credenziali degli utenti in maniera criptata all’interno di un directory server (aderente allo standard LDAP v3) ed effettua il caching in un formato criptato all’interno della Workstation dell’utilizzatore finale (per ottimizzare il tempo di sign-on o 6 di 43 garantire il funzionamento a utenti laptop). L’unico utente abilitato a sbloccare i dati criptati contenuti nella cache della Workstation rimane sempre e comunque l’utente stesso. L'amministratore non ha in alcun modo accesso alla copia delle credenziali dell'utente. L'architettura di NSL è su 2 livelli: agent sulle postazioni e back-end rappresentato dall'infrastruttura di directory o LDAP. Non sono presenti middleware o repository aggiuntivi. Anche la console di amministrazione dialoga direttamente col back-end senza intermediari. Novell Secure Login: l’architettura I dati memorizzati da SecureLogin sono il record delle credenziali di autenticazione utente e le istruzioni riguardanti la modalità di utilizzo di tali credenziali, ovvero gli script di login sulle applicazioni o sugli emulatori su cui effettuare single sign-on. Per la memorizzazione delle credenziali, SecureLogin può avvalersi di svariate alternative: • • • • un qualsiasi directory compatibile con le specifiche LDAP v3; Microsoft Active Directory anche sia in Application Mode (ADAM); Novell eDirectory; Novell eDirectory + Secret Store Server. L'uso di ActiveDirectory come back-end è tipicamente associato alla connessione fra client NSL e ActiveDirectory via normale client Windows (in alternativa è possibile usare AD come LDAP server "puro"). Ciò apporta almeno due benefici: • • non dovere introdurre un’ulteriore infrastruttura di back-end, ereditare la robustezza e affidabilità server-side dell'infrastruttura AD esistente. NSL può usare ADAM in congiunzione ad Active Directory (AD per autenticazione di rete, ADAM per memorizzare dati, policy e configurazioni) qualora il cliente non voglia estendere lo schema di Active Directory. La connessione fra NSL e ADAM è necessariamente in LDAPS (in generale, qualora si desideri usare un LDAP server come back-end, la connessione è obbligatoriamente in LDAPS per NSL). Il vantaggio di usare ADAM per NSL, è quello di non dovere estendere lo schema di AD con gli attributi di NSL. SLManager è lo strumento di NSL deputato all'amministrazione quando il back-end è di tipo LDAP server. L'infrastruttura ADAM in alta disponibilità è potenzialmente distribuita tanto quanto quella AD per meglio servire le postazioni distribuite geograficamente. Nel caso si usi come repository Novell eDirectory ci si può avvalere del Secret Store, una estensione funzionale di eDirectory che permette un livello di riservatezza superiore a quello disponibile in caso si usi SecureLogin avvalendosi di altre piattaforme LDAP. Il Secret Store infatti prevede per ciascun utente la conoscenza sia di una Password (soggetta a variazione periodica ed eventualmente passibile di ovveride da Help desk o amministratori) sia di una Passphrase (non soggetta a variazione, classicamente definita come risposta ad una challenge question, ad es: nome della maestra elementare). Il modello a doppia chiave permette di gestire in maniera sicura il password ovveride di cui all’esempio di caso d’uso seguente: se un utente dimentica la propria password e l'help desk la sovrascrive, prima di poter usare nuovamente NSL verrà chiesto all'utente di ridigitare la Passphrase. In altre parole, le credenziali segrete mantenute nel secret store sono soggette a lock in seguito al password ovveride (ma non in seguito a password change effettuato da parte dell'utente stesso) e sono sbloccate solo in seguito all'inserimento della Passphrase. Questo modello esclude la possibilità per operatori di Help Desk o amministratori di impersonare utenti terzi previo password ovveride. In caso la Passphrase venga dimenticata l'help desk può solo resettare totalmente l'utente, cancellando integralmente tutti o segreti. Le credenziali sono memorizzate cifrate sia lato server (directory) e sia sulla cache locale all'agent sulla postazione utente. La cifratura è tale che nemmeno un amministratore può leggerle (ma solo eventualmente resettare una password come operazione di help desk). La cifratura può essere di tipo 3-DES o AES. La comunicazione fra client NSL e server (AD, eDir, LDAP) avviene sempre in modalità riservata e cifrata (protocolli nativi per AD/eDir, LDAPS per server LDAP). Dal punto di vista funzionale, NSL supporta autenticazioni con username/password e autenticazioni forti (integrazione con smart card ad es.) e combinazioni di più fattori di autenticazione. La totalità delle configurazioni specifiche per il funzionamento dell'agent sulla workstation vengono caricate a tempo di esecuzione dall'agent prelevandole dal directory server. Non sono quindi memorizzate sulla workstation stessa. Sono infatti memorizzate centralmente sul directory: • • • tutte le policy di funzionamento dell'agent, tutti gli script di automazione del logon sulle applicazioni, questo implica che, quando viene aggiunto o modificato lo script di integrazione di una applicazione, non sono necessarie ridistribuzioni di software sugli agent, tutte le credenziali di ciascun utente per ciascuna applicazione. In altre parole, la configurazione in fase di installazione dell'agent richiede solo dei parametri di base del tipo: • • • quale tipo di directory server viene utilizzato (AD, eDirectory, Altro LDAP), qual è l'indirizzo dei directory servers, in quale modalità il prodotto deve funzionare (con o senza SecretStore, con o senza Novell Client). Strumenti di amministrazione Gli strumenti di amministrazione (iManager per Novell eDirectory, SLManager per LDAP server e ADAM, snap-in ad hoc per la MMC per Microsoft ActiveDirectory) dialogano col back-end e non ne influenzano la scalabilità (si può agire su un qualsiasi directory server, le configurazioni vengono automaticamente replicate su tutti). L'amministrazione server-side di NSL in ambiente AD è effettuata con snap-in ad hoc per la Microsoft Management Console forniti col prodotto e installabili su una qualsiasi workstation assieme al "Remote Server Administration Tools for Windows 7 " o equivalente per WinXP/AD2003. Non è quindi necessario avere diritti di amministratore di dominio e accedere a un domain controller per amministrare NSL. Le best practice consolidate in diversi anni di progetti hanno portato a definire 2 ruoli per l'amministratore di NSL ("SecureLogin Administrator" e "SecureLogin Help Desk"). Questo tipo di approccio permette di delegare l'amministrazione ordinaria della soluzione a un gruppo di operatori autonomi senza interferire con la gestione generale dell'infrastruttura AD e senza possibilità di effetti collaterali (l'insieme di attributi NSL che estendono lo schema sono indipendenti da tutto il resto). Application Definition Le application definition sono gli scripts che contengono la definizione del comportamento dell'agent di NSL rispetto alle maschere di autenticazione su applicazioni Win32/.NET, web (anche con Applet Java), Java (supporto specifico anche per Oracle Forms) ed emulatori di terminali. La creazione di tali scripts avviene mediante l'uso di una procedura guidata (wizard) che permette di costruire passo-passo lo script in maniera grafica e intuitiva. Lo script può essere poi affinato successivamente. Il linguaggio di scripting di SecureLogin permette inoltre di implementare procedure di login sofisticate: ad esempio sopporta la gestione di differenti script di login per versioni diverse della stessa applicazione. NSL permette di associare un set di credenziali a N applicazioni e ogni utente può avere M set di credenziali. Ad ogni applicazione può quindi essere associato un differente set di credenziali. In generale, la relazione fra l'insieme delle applicazioni e quello delle credenziali è di tipo N:M. Il prodotto inoltre fornisce un set di script preconfigurati per le seguenti applicazioni: 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7 3.1.8 ActiveSync* Cisco* VPN Citrix Program Neighborhood Citrix Program Neighborhood - Farm Login Failure Citrix Program Neighborhood - Server Citrix Program Neighborhood - Agent Citrix Program Neighborhood - Agent v10.x GroupWise Windows Application v5.5, v6.0, v7.0, and v8.0 3.1.9 Lotus* Notes* R8 3.1.10 MEDITECH* x and 4.x 3.1.11 Microsoft Internet Explorer 6, 7, and 8 3.1.12 Microsoft Networking Client 3.1.13 Microsoft Outlook* 3.1.14 Microsoft Outlook Express 3.1.15 Microsoft SQL 3.1.16 Microsoft Windows Live ID 3.1.17 MSN Messenger 4.5 and 4.7 3.1.18 Novell Groupwise Messenger 2.0 3.1.19 Novell Groupwise Notify Client 3.1.20 Novell Groupwise 7.0 Web Login 3.1.21 Novell iManager Web Login 3.1.22 Quick Finder 3.1.23 SAP - SAPlogon.exe 3.1.24 SAP R/3 Login 3.1.25 Trillian* 3.1.26 VNC 3.0 and 4.0 3.1.27 Windows Live Messenger 5.0, 6.0, 7.5, 8.1, and 2009 3.1.28 Windows Remote Desktop 6 3.1.29 Yahoo! Messenger 8.1 3.1.30 Yahoo! Messenger 8.1 Alternate 3.1.31 AbsoluteTelnet 3.1.32 Attachmate* Extra 3.1.33 Attachmate Extra 2000 3.1.34 Attachmate KEA! 3.1.35 Attachmate Personal Client 3.1.36 Chameleon HostLink* 3.1.37 CRT 3.1.38 Eicon Aviva* 3.1.39 GLink 3.1.40 HBO* Star Navigator 3.1.41 IBM* Personal Communications 3.1.42 IDXTerm Healthcare 3.1.43 Info Connect 3.1.44 Microsoft Telnet 2000 3.1.45 Microsoft Telnet NT 3.1.46 Microsoft Telnet Win 9x 3.1.47 Mocha W32 Telnet 3.1.48 NetTerm 4.2 3.1.49 NS/Elite* 3.1.50 Passport TN 3270E 3.1.51 PowerTerm* 3.1.52 3.1.53 3.1.54 3.1.55 QVT QWS3270 Plus SDI TN3270 TeraTermPro 3.1.56 TinyTERM 3.1.57 ViewNow* 3.1.58 Wall Data Rumba* 3.1.59 Wall Data Rumba 2000 3.1.60 Wall Data Rumba Web To Host 3.1.61 WinComm 3.1.62 Window Telnet VT 3.1.63 WRQ Reflection* 3.1.64 Citrix Web Portal 3.1.65 CNN Member Services 3.1.66 eBay 3.1.67 Fidelity.com Web Login 3.1.68 Hotmail 3.1.69 Onebox.com 3.1.70 Qantas Frequent Flyer 3.1.71 Yahoo! Mail 3.1.72 Monster.com Random Password Generation Client e Server side NSL permette di implementare modelli di generazione random della password gestiti client side: l'agente sulla workstation effettua la sostituzione della password su una data applicazione con una password casuale non nota all'utente. La nativa integrazione tra le componenti della suite IAM Novell permette anche l'implementazione di un modello server side di Random password management usando esclusivamente componenti di prodotto e senza sviluppi custom. Tutti i driver di Novell Identity Manager …..comprendono la possibilità di generare password random e di scrivere le credenziali nel repository di NSL (sia esso il SecretStore o meno). E' quindi possibile evitare all'utente la necessità di sapere anche la password iniziale di accesso ad una applicazione in quanto Novell Identity Management può “dirla” a Novell Secure Login in fase di provisioning dell'utenza. Ciascuna operazione di provisioning quindi provvederà sia alla definizione della password (random) per l'applicazione specifica (es SAP, Notes, ecc.) sia all'aggiunta della stessa password alla lista delle credenziali di accesso per NSL. Rispetto al modello Client side, la disponibilità aggiuntiva del modello Server side permette di gestire il refresh delle password random anche in modalità batch a frequenza configurabile senza che l'utente ne venga informato o che debba necessariamente accedere all'applicazione. Uso di Smart Card in Secure Login Per sua natura SecureLogin utilizza un approccio di tipo “store-and-forward” nella gestione delle credenziali di SSO memorizzando gli ID utente e le password nello storage server side. Ne consegue l'estrema importanza della sicurezza del repository delle credenziali di SecureLogin.L'uso congiunto di smart card e SecureLogin rende disponibili funzionalità utili ad aumentare la sicurezza delle credenziali. Ad esempio: • • • Uso della smart card per criptare le credenziali di SecureLogin, Salvataggio anche sulla smart card delle credenziali di SSO delle applicazioni, richiedere il log on a mezzo smart card per lanciare ed amministrare il SSO. SecureLogin usa un processo di encryption a due livelli per mettere in sicurezza utenti, credenziali e dati sensibili. Tutte le password utente sono criptate mediante una “chiave utente”, mentre tutti i dati relativi all’utente, inclusi i campi password, sono criptati usando una “chiave master”. Il risultato è una encryption a due livelli, dove i valori di password sono criptati due volte: una volta con la chiave utente e una volta con la chiave master, mentre tutti gli altri dati sono criptati una volta sola con la chiave master.L’utilizzo di SecureLogin unitamente ad una smart card fornisce un livello aggiuntivo di sicurezza perché la chiave usata per decodificare i dati è salvata sulla smart card, e l’autenticazione avviene mediante un duplice fattore: la smart card (possesso) e il PIN (conoscenza di informazione). Se si seleziona l’opzione “uso della smart card per criptare i dati di SSO”, perché SecureLogin venga caricato gli utenti devono prima inserire la smart card e fornire il PIN personale. Integrazione con sistemi di Identity management In questo paragrafo descriviamo come NSL si potrà integrare con un altro prodotto Novell: Identity Manager (IDM). Il modulo di “Credentials Provisioning” di Novell Identity Manager (IDM) consente di effettuare il provisioning delle credenziali usate per connettersi a una applicazione con Novell SecureLogin (NSL) all'attivazione dell'account specifico, a un cambio password o a un qualsiasi altro evento in ambito identity management. Si osservi che non è necessario che il repository utenti dell'applicazione acceduta via NSL sia integrato nella soluzione di Identity Management. I vantaggi derivanti dal provisioning automatizzato delle credenziali (e successive modifiche) ha un duplice beneficio: - semplificazione delle procedure di delivery e manutenzione della soluzione di Enterprise Signle Sign On (ESSO) - rafforzamento della sicurezza complessiva. Se un sistema è connesso via IDM e acceduto via NSL, è infatti possibile effettuare provisioning di password generate casualmente e sconosciute agli utenti. In questo modo, gli utenti possono accedere a queste applicazioni solo attraverso NSL. Qualora si decida di richiedere un’autenticazione forte per l'accesso a NSL, il beneficio è ereditato da tutte le applicazioni. È possibile inoltre cambiare le password in automatico per quelle applicazioni che non prevedono la funzionalità di cambio password nativamente. Anche la passphrase di NSL (meccanismo di ulteriore sicurezza per sbloccare NSL sul client) può essere gestita dal modulo di Credentials Provisioning. Qualora IDM non sia parte della soluzione, è l'utente o l’amministratore di sistema a inserire le proprie credenziali per ogni applicazione al primo uso, in modo che NSL le registri. Architettura della soluzione Al fine di avere un minor impatto possibile con l'attuale configurazione di rete presente in ospedale, il backend verrà installato in macchine separate contenenti due istanze di Active Directory in Application Mode (ADAM) in replica multimaster. In questo modo non sarà necessario aggiungere schemi all'Active Directory di produzione, in quanto tutti i dati relativi a Novell Secure Login saranno memorizzati nelle istanze ADAM. Gli utenti saranno quindi autenticati dall'Active Directory attualmente utilizzato, e NSL accederà alle istanze ADAM per reperire informazioni riguardo a configurazioni, template, policy ed account degli utenti. Occorre notare che, anche se ADAM non conterrà informazioni sulle credenziali AD dell'utente, NSL manterrà in memoria la password AD dell'utente, in modo da poter automatizzare l'accesso ad applicativi che effettuano l'autenticazione su Active Directory. Active Directory ed Adam verranno sincronizzati tramite il tool ADAM Synchronizer, tramite cui, quando un utente viene creato su AD, viene aggiunto automaticamente anche su ADAM. La cancellazione di un utente e le modifiche di Organizzation Unit invece non sono sincronizzate automaticamente, ma mediante task che verranno schedulati o potranno essere eseguiti manualmente. La gestione di utenze viene effettuata tramite Novell SLManager, che estende i tool di amministrazione di ADAM in modo da supportare la gestione delle funzionalità di Novell SecureLogin.