Integrazione con altri sistemi

Il nostro sistema dovrá interagire con gli altri sistemi presenti in azienda, la struttura aziendale risultate, a livello logico, avrá una forma a stella, uno schema rappresentativo del sistema che dovrà risultare al termine del progetto é rappre-sentato in gura 3.2. E' utile avere un'idea di come procedere prima di iniziare il progetto, in modo da non trovarsi spiazzati nelle fasi seguenti.

Figura 3.2: Schema dell'integrazione trai vari sistemi presenti in azienda, il log mining dovrà inserirsi in questi sistemi

Implementazione Raccolta

In questo capitolo verranno descritte le fasi che hanno contraddistinto la con-gurazione del sistema di logging per adempiere alla legge anti-terrorismo e per tentare di fornire una base per l'identicazione dei problemi di rete, in questa fase sono stati già selezionati i logs che verranno utilizzati nel progetto, e sono stati, quindi, specicati anche i dati che da essi verranno estratti. La priorità, come è prevedibile, è stata assegnata alla messa in regola rispetto alle leggi 144,155 (denito pacchetto Pisanu 3.2).

Una volta deniti i dati e le priorità, è stato necessario eettuare valutazioni sulla sicurezza del sistema, andando a testare l'eettiva inviolabilità del server e sulla dimensione dei dati che si andranno a memorizzare, cosa che ha imposto la creazione di sistemi per organizzare al meglio, mediante automatismi, il server centrale di raccolta e i dati in esso contenuti.

4.1 Riepilogo obiettivi pressati

Il progetto ha lo scopo di realizzare un sistema integrato per la gestione delle reti Wireless sollo il controllo e la responsabilità di Telerete NordEst, il controllo degli accessi a questa rete verrà adato ad un applicativo che si basa sull'analisi dei log, un sistema non invasivo dal quale si possono ricavare molte informazioni circa l'andamento e l'utilizzo della rete. Al contrario di altri sistema di monitoring di rete, questo non crea traco al momento delle richieste, le informazioni sono già presenti nei logs, i quali saranno stati, precedentemente, centralizzati. Il nostro obbiettivo è di utilizzare questi log come risorsa, non solo per adempiere ad ob-blighi legislativi, ma anche per studiare l'andamento della rete, rilevare eventuali

4.1 RIEPILOGO OBIETTIVI PREFISSATI malfunzionamenti e saper rispondere in fretta, e possibilmente in maniera auto-matizzata, a determinate problematiche.

L'obiettivo generale dell'analisi dei log è quello di trarre informazioni utili ed immediatamente fruibili, partendo da dati di cui si é già in possesso, senza cioè alcuna attività aggiuntiva di ricerca delle informazioni.

Tali log non sono idonei ad essere analizzati da un operatore umano, in quanto soggetto a limiti di tempo, attenzione e possibilità di errore.

La possibilità di ottenere informazioni nuove è legata, quindi, alla capacità di au-tomatizzare la raccolta, l'analisi e l'interpretazione di grossi moli di log provenienti da macchine ed applicativi eterogenei. Trarre informazioni utili ed immediata-mente fruibili da dati in possesso è il punto di forza del process mining.

Nel caso di una rete complessa, comprendente variabili quali host, servizi ed utenti, per ottenere informazioni generali, è necessario disporre di una buona base di dati, da incrociare ed interpretare, i dati in causa vengono forniti dai log generati dai vari nodi componenti la rete e dai vari servizi associati. Questi log presi singolarmente non sarebbero in grado di descrivere la rete in cui si trovano, nè di fornire nuove informazioni che non siano direttamente osservabili dai dati grezzi ricevuti in input. La possibilità di inferire informazioni nuove e legata alla identicazione di variabili che siano il più possibile slegate dal singolo nodo della rete o dal singolo log e che siano invece legate a fattori che condizionano l'intera rete e ne descrivano caratteristiche sensibili.

Il ne della raccolta sarà quindi quello di fornire dati ed identicare variabili da utilizzare per uno o più algoritmi di process mining, nel caso in cui si riuscisse a calare un processo alla rete.

Bisogna tenere presente che queste variabili devono essere deducibili dai log, mediante lettura diretta o lettura incrociata dei dati contenuti nei vari log e non devono coinvolgere altre attività speciche, devono cioè essere informazioni che arrivano senza costi aggiuntivi ed unicamente dall'osservazione di questi. Le variabili devono essere inoltre deducibili con un costo preventivato e sostenibile, spesso infatti i log sono dell'ordine di Gigabyte e prodotti nell'arco di millisecondi, e non è ipotizzabile una loro analisi in tempo reale.

Il prodotto ultimo sarà un sistema distribuito su più macchine, con funzio-nalità che andranno dalla raccolta dei log, alla loro reperibilità, interrogabilità e disponibilità, al ne di creare un sistema di integrazione delle informazioni a benecio dei sistemisti di rete.

Più praticamente il sistema dovrebbe guidare un operatore nella ricerca di even-tuali malfunzionamenti dell'infrastruttura di rete, suggerendo dei test eettuabili, e, per alcuni test, fornire già delle risposte deducendole dai logs.

L'idea di fondo è che, molte informazioni, possono essere estratte dai log senza bisogno di eseguire dei test specici, che utilizzino nuovamente la rete per ritornare un esito positivo o negativo. Nel caso più semplice, un host `down', può essere recepito da una assenza di log di traco, piuttosto che da un ping attivo sulla macchina (anche in assenza di attività un host ha comunque un certo traco ARP o di altro genere per mantenere la connessione alla rete, quindi per mancanza di traco nei log si intendono sessioni di utilizzo attivo della rete).