You are currently browsing the category archive for the ‘Esercizio’ category.
La gestione degli aspetti di Authentication, Authorization ed Accounting (AAA) riveste un’importanza fondamentale per la sicurezza sia delle applicazioni usate all’interno dell’azienda stessa che di quelle utilizzate per proporre servizi alla propria clientela.
Questo a maggiore ragione in questi ultimi anni in cui la legge sulla privacy ha introdotto ulteriori requisiti e spostato la sicurezza da un solo concetto di difesa per chi eroga un servizio ad un meccanismo di difesa di chi usa quel servizio e come tale è costretto a fornire dati sensibili.
Le attuali soluzioni di Identity Management che implementano le funzioni di AAA hanno risolto egregiamente gli aspetti di Autenticazione che, tramite il Single Sign-On, permettono inoltre di unificare e centralizzare il controllo e la profilazione degli utenti.
Questo non è vero per quanto riguarda l’Autorizzazione soprattutto se questa è intesa come gestione dell’entitlement (cosa un utente è abilitato a fare) di tipo totalmente centralizzata, fortemente granulare e con alto gradi di dinamicità.
Ad oggi molto spesso la gestione dell’entitlement è implementata all’interno della singola applicazione rendendo difficile, se non impossibile la gestione dell’Autorizzazione in una architettura orientata ai servizi, dove l’applicazione non conosce a priori il contesto nel quale il servizio che offre viene “consumato”.
Ma cosa si intende esattamente per Entitlement?
La parola entitlement, specialmente se tradotta dal dizionario, può significare cose diverse a persone diverse. In questo contesto, per entitlement si intende un insieme di privilegi che governano quello che l’utente di una applicazione è abilitato a fare.
Un entitlement è la relazione tra una risorse dell’applicazione (o in forma più astratta un oggetto di business) e l’insieme di utente/gruppo/ruolo, rappresentata secondo una struttura gerarchica.
Gli entitlement:
- sono soggetti ad una massima proliferazione;
- necessitano di considerare diverse informazioni di contesto prima di effettuare una decisione;
- devono essere consistenti all’interno dell’infrasttuttura e all’insieme delle applicazioni;
- devono essere allineati con i sistemi di Identity Management;
- devono evolvere indipendentemente dalle applicazioni e dai servizi;
Tuttavia….
ad oggi la maniera più comune di implementare gli entitlements è cablarli nel codice dell’applicazione!!!
Per rispondere a questa esigenza BEA ha sviluppato la soluzione BEA AquaLogic Enterprise Security che permette di esternalizzare, unificare e semplificare la gestione delle politiche di autorizzazione ovvero degli entitlement.
La figura seguente mostra un esempio di applicazione di trading. Questa applicazione può essere usata da differenti tipologie di utenti, ma solo gli utenti che sono traders possono fare operazioni di acquisto/vendita. Inoltre, i traders posso operare solo per gli specifici conti per i quali sono autorizzati e solo fino ad uno specifico importo per ogni definito per ogni conto.
Come si può vedere nel secondo caso, la decisione è rimossa dall’applicazione e valuta a runtime dal motore di BEA AquaLogic Enteprise Security.
Utilizzando BEA AquaLogic Enterprise Security all’interno della propria infrastruttura si possono quindi definire le linee guida con cui devono essere sviluppate le applicazioni per quanto riguarda la funzionalità di gestione dell’Autorizzazione, ovvero:
- nessuna policy cablata nel codice
- nessuna policy dipendente da un file di configurazione
- scrittura del codice uniforme verso un unico layer per la gestione della sicurezza
Come funziona AquaLogic Enteprise Security in dettaglio?
Al prossimo post…
Per aiutarvi ad ottenere le prestazioni ottimali dai vostri sistemi sono oggi disponibili molti strumenti di Monitoraggio e Analisi.
Tuttavia non vi saranno di aiuto o potrebbero additrittora contribuire ad accrescere i problemi prestazionali se usati in modo improprio.
Per ottenere le prestazioni ottimali dalle vostre applicazioni WebLogic, dovrete guardare al di là degli strumenti automatizzati e rispondere ad alcune domande relative al vostro business.
Questo post (ne seguiranno altri sullo stesso tema) vuole evidenziare le domande che ogni cliente dovrebbe chiedersi quando si analizzano problemi prestazionali.
Ovviamente la lista di domande possibili è potenzialmente infinita, ma vorrei evidenziare le motivazioni più comuni per cui sorgono problemi prestazionali.
Tante variabili e sempre poco tempo….
E’ importante notare che l’analisi prestazionale è un’arte, più che una scienza esatta. Buone prestazioni sono raggiungibili con compromessi e bilanciamenti ragionati.
Cosa volete ottenere?
Queste sono alcune delle ragioni, rilevate dalle mie esperienze con Clienti con problemi sorti durante la messa a punto dell’Application Server.
– Avere migliori tempi di risposta
– Raggiungere o superare i Service Level Agreement
– L’efficienza della JVM (Java Virtual Machine)
– Capire perchè il sistema rallenta ad una certa ora il venerdi pomeriggio
– Durante i test tutto “girava” alla perfezione, ora che l’applicazione è in produzione invece sembra essere molto lenta nelle esecuzioni
“Forse perchè…”, “rivediamo le configurazioni…”, “proviamo a fare…” non sono ovviamente risposte accettabili.
Queste domande meritano una risposta puntuale.
Chi deve essere soddisfatto delle prestazioni?
Rassegnatevi al fatto che non potrete rispondere a tutte le richieste di aumento prestazionale che arrivano dal management o dagli utenti di business della vostra Azienda.
Dovrete esculdere i problemi che risultano ad di là della vostra capacità o autorità di intervento.
Risorse finanziarie ridotte, disponibilità limitata di risorse adeguate, politiche aziendali, e infrastrutture informatiche limitate sono alcune delle barriere che potreste incontrare. In questo caso potreste avere poca o nessuna possibilità di intervento.
Focalizzatevi sull’elenco di elementi su cui potete avere sicuramente un impatto positivo, ed eliminate quelli che non potete modificare.
Con questa lista considerate da quali elementi potete partire subito, i problemi che, se risolti, potrebbero portare un maggiore beneficio alla vostra Azienda, e il costo per indirizzare ogni problema..
Prima di partire, dovreste anche individuare “chi” state cercando di soddisfare, e quindi date una priorità alla vostra lista.
Nella prossima puntata… “Cosa misurare???”
Nella versione di Guardian rilasciata agli inizi di Febbraio 2008 ci sono novità significative.
Durante lo scorso anno abbiamo avuto indicazioni da molti Grandi Clienti che ritenevano che l’auto installazione (auto-deploy) dell’Agente di Guardian fosse in contrasto con le policy di sicurezza e di auditing in essere.
Per queste ragioni abbiamo rimosso, a partire da Guardian 1.0.7, la funzione di auto-deploy, e di conseguenza l’Agente dovrà essere installato manualmente, ad esempio tramite la BEA WebLogic Console.
Nel prossimo futuro, a partire dalla release WLS 10.3, l’Agente Guardian sarà incluso direttamente in WLS Server e non sarà più necessario installarlo.
Per maggiori informazioni e per scaricare gratuitamente BEA Guardian cliccare QUI
Sviluppato come guida per il governo del Regno Unito, l’Information Technology Infrastructure Library (ITIL) è uno standard nato alla fine degli anni ’80 con lo scopo di offrire una serie di “best practice” per la gestione dei servizi IT, promuovendo un approccio di qualità al fine di ottenere maggiore efficacia nel lavoro e sempre più efficienza nell’utilizzo dei sistemi informativi.
Il crescente affermarsi sul campo di questo standard dipende dal riconoscimento e dall’adesione da parte di quelle organizzazioni che, in modo sempre maggiore, sono dipendenti dall’Information Technology, e che sono decise a soddisfare i loro scopi e le loro necessità di affari.
Questa dipendenza conduce alle necessità di servizi di qualità dell’IT sempre maggiori, qualità per la quale lo standard ITIL fornisce una serie di indicazioni da seguire.
Esso, infatti, descrive i processi, le attività, i ruoli e le responsabilità per poter gestire in modo flessibile l’organizzazione e i problemi che possono sorgere, al fine di migliorare la qualità dei servizi forniti e di rispondere alle esigenze del mercato, dei clienti e degli acquirenti. ITIL è supportato da uno schema di qualifica completo, da organizzazioni accreditate di training, e da strumenti di implementazione e di valutazione.
Questo insieme di “best practice”, in sostanza, non si presenta come una serie di rigide regole, ma più semplicemente come una traccia da adattare caso per caso a seconda delle necessità, dei bisogni, delle particolarità e delle caratteristiche dell’azienda. Lo standard può essere utilizzato:
-
nel settore pubblico – Governo centrale e locale, Autorità sanitarie e politiche
-
nel settore privato – Banche, Assicurazioni, Telecomunicazioni, Servizi Pubblici, Trasporti
-
dalle società IT – Fornitori di prodotti, Società di System Integration, Società di Outsourcing
La documentazione ITIL è suddivisa in più libri, che trattano ognuno un aspetto diverso della gestione dei servizi IT; sono tutti leggibili in modo indipendente, ma ovviamente presentano sempre concetti strettamente correlati tra di loro. I libri di cui la documentazione è composta sono i seguenti:
SERVICE SUPPORT :
assicura che il Customer abbia accesso ad appropriati servizi per il supporto di funzioni di business. I processi descritti sono: il Service Desk, l’Incident Management, il Problem Management, il Configuration Management, il Change Management e il Release Management.
SERVICE DELIVERY :
questa sezione riguarda il rilascio del servizio richiesto per permettere un supporto adeguato ai clienti. Vengono trattati i processi del Capacity Management, del Financial Management per i Servizi dell’IT, dell’Availability Management, del Service Level Management e dell’IT Service Continuity Management.
PIANIFICAZIONE PER IMPLEMENTARE IL SERVICE MANAGEMENT :
questa parte introduce all’utilizzo dell’ITIL in quanto fornisce una guida sull’allineamento dei bisogni di business all’IT e sulla valutazione dei livelli correnti di maturità del Service Management. Aiuta l’organizzazione ad identificare i punti di forza e di debolezza, permettendo di sviluppare i primi e di superare gli ultimi.
ICT INFRASTRUCTURE MANAGEMENT :
si occupa dei processi, dell’organizzazione e degli strumenti necessari per fornire un’infrastruttura stabile di IT e comunicazioni ed è la base per i processi di ITIL Service Management. Questa parte si occupa di Design & Planning, Operations e Technical Support.
APPLICATION MANAGEMENT :
fornisce un aiuto agli utenti, agli sviluppatori e ai manager del servizio per identificare quali applicazioni possono esser gestite da una prospettiva di service management.
SECURITY MANAGEMENT :
questa sezione si occupa della sicurezza dal punto di vista del fornitore del servizio, identificando come il Security Management si relaziona con l’IT Security Officer e come fornisce il livello di sicurezza necessario.
THE BUSINESS PERSPECTIVE :
si occupa di far comprendere ai manager il carico di business. Le questioni trattate includono il Business Relationship Management, il Partnership and Outsourcing, dei continui miglioramenti e sfruttamenti dell’informazione, Communication and Technology (ICT) per trarre vantaggio dal business.
La figura seguente mostra i processi che fanno parte dell’area “Service Support”
Ogni processo ITIL è a se stante nella sua definizione, ma per svolgere pienamente il suo scopo deve essere preso in considerazione con tutti gli altri.BEA Systems ha adeguato la propria struttura di supporto per essere in linea con le Best Practices ITIL, con particolare riferimento al Service Support, e inoltre richiede che i Support Account Manager che hanno la responsabilità dei Clienti di tipo Mission Critical siano certificati ai maggiori livelli ITIL. Come a dire: “al vostro servizio” con le nostre “migliori risorse”.
Per informarsi o saperne di più www.itsmf.it
Chiara Scarafiotti, ITIL Practitioner Support & Restore
Attualmente, nell’industria del software il Supporto Clienti rientra in una delle seguenti categorie: il supporto proattivo e il supporto reattivo.Il supporto proattivo (in BEA è rappresentato dal livello di Supporto deniminato Mission Critical) rappresenta un approccio intensivo alla risoluzione dei problemi di sistema individuati, prima che questi ultimi provochino tempi elevati di inattività o influiscano sulla produttività e sul business dei Clienti. Con il supporto proattivo si controllano i sistemi e interviene sulla causa principale di un problema prima che si aggravi.Il supporto reattivo, al contrario, risolve i problemi dopo che essi hanno già avuto qualche impatto sulle applicazioni e sul business, cercando di eliminare il problema esistente e di ripristinare il normale funzionamento del sistema.Tuttavia, sia il modello di supporto proattivo che quello reattivo lasciano talvolta i Clienti insoddisfatti. Entrambi i tipi di supporto possono risultare dispendiosi, sia in termini di tempo che di denaro; infatti entrambi i modelli implicano che il problema si verifichi prima che sia possibile intervenire. L’identificazione e la risoluzione dei problemi esistenti possono richiedere un numero maggiore di ore di lavoro e di impiego di risorse.BEA sa che i sistemi complessi rappresentano il centro nevralgico delle aziende dei Clienti, che non possono certo affidarsi solo a questi modelli di supporto “guasto/riparazione”. I nostri Clienti richiedono sempre di più un supporto continuo (24 ore al giorno, sette giorni su sette), in grado di identificare i potenziali problemi prima che si verifichino.Necessitano inoltre di un paradigma di supporto assolutamente affidabile.BEA ha quindi indicato una nuova tipologia di supporto, che ha chiamato “preventivo“.BEA Guardian è la risposta di BEA alle esigenze precedenti, individuate grazie ad approfondite ricerche e analisi sul campo. (Scaricate le analisi di Forrester Research)Le ricerche eseguite da BEA indicano che oltre il 40% dei problemi sono dovuti a errori di configurazione e amministrazione.L’identificazione dei problemi di configurazione e amministrazione e l’elaborazione dei relativi report garantiscono che l’implementazione disponga di patch, impostazioni di configurazione e altri attributi corretti. BEA Guardian notifica persino gli eventuali conflitti di configurazione con le best practice applicate da BEA.BEA Guardian è uno strumento intuitivo per il supporto di sistema preventivo, progettato per individuare i potenziali problemi prima che questi richiedano l’intervento del personale di supporto IT o influiscano negativamente su operazioni e clienti.BEA Guardian consente inoltre di ottimizzare le implementazioni e le operazioni giornaliere.Se l’installazione di BEA Guardian dispone di connettività Internet, è anche possibile trarre vantaggio dalla creazione diretta di Chiamate (CASI) al BEA Customer Support, nonché dagli aggiornamenti automatici.Per saperne di più e per scaricare documenti e prodotto visitate la pagina “BEA Guardian” sul sito www.bea.com
Storie di vita vissuta in Esercizio … sono le 18.30 di venerdi, e il vostro sistema che ospita applicazioni business critical segnala problemi, ed ha crollo “psicofisico”. Noooo ! Vi mettete le mani nei capelli e aprite cercate subito di aprire un CASE al Supporto BEA. La vostra Azienda sta perdendo business ($$$) ed il Customer Support di BEA, grazie al processo “Follow The Sun (FTS)”, è lì per aiutarvi. Tra i vostri tecnici e i nostri specialisti si puo’ creare un team virtuale che indirizzarà il problema e lo risolverà velocemente.Come fare? Voi aprite un CASE come sempre quando vi capita un problema, ovvero segnalate al Customer Support di BEA che il software “BEA XYZ” vi segnala un errore (ricordatevi di descrivere l’errore). Poi chiamate il BEA Customer Support (numeri di telefono) e chiedete a chi vi risponde di innalzare la Severity del problema a 1 (Severità massima). Inoltre chiedete di assegnare il Case secondo la procedura “Follow The Sun (FTS)” perchè avete bisogno che venga seguito da subito e per tutte le 24 ore; vi sarà quindi richiesto di fornire contatti dei vostri tecnici che saranno di volta in volta disponibili per seguire il CASE durante le 24 ore insieme agli ingegneri del Supporto BEA, fornendo le informazioni e i file necessari alle analisi e applicando le eventuali correzioni suggerite.Come funziona il FTS? Questo procedimento fa si che il vostro CASE venga trasferito da un Centro di Supporto all’altro secondo la rotazione terrestre: ad esempio, voi siete in Europa e il Centro di Supporto che vi sta seguendo è Parigi, Londra o Monaco; senza FTS quando i centri di supporto terminano l’attività giornaliera i CASE vengono lasciati per riprendere la loro lavorazione ed analisi la mattina dopo; con FTS attivato invece il vostro CASE, alla chiusura dell’attività in Europa, viene trasferito nei Centri di Supporto in America dove verrà continuata la sua analisi, e successivamente in Asia, per ritornare all’ingegnere di Supporto in Europa la mattina dopo. Il processo FTS è efficace solo se anche il Cliente è a disposizione per le 24 ore, in quanto durante l’analisi potrebbe essere necessario un contatto per test o per richiedere ulteriori informazioni necessarie all’eseme della situazione. In questo modo l’attività di ricerca e di ripristino / risoluzione non si ferma mai e il problema potrà essere risolto in prima possibile. Ulteriori info qui.La “Liquidity” delle informazioni di Supporto che fanno il giro del mondo è la chiave per la vostra capacità di supportare il Business Aziendale.
Caffè con BEA 