Risposte esame Sistemi informativi aziendali

utente o alla descrizione dell'oggetto) oppure MAC cioè in base a politiche mandatorie, utili nel caso di dati sensibili. Elementi caratteristici del protocollo MAC:

• Classificazione di tutti i dati (in base al livello di sensibilità: Unclassified, Confidential, Secret, TopSecret)
• Base di Dati multilivello (MLR cioè Multi-Level Relation) cioè la presenza simultanea di più copie fisiche della stessa tabella separate a seconda della classificazione di sicurezza, questo avviene tramite polinstallazione

L'accesso alla MLR può avvenire nei seguenti modi:

• Lettura: un soggetto può accedere in lettura alle istanze di una MLR al proprio livello o al di sotto
• Scrittura: può generare polinstanziazione se l'elemento da inserire esiste già con quel nome - se il soggetto richiedente ha una classificazione più bassa o non comparabile rispetto a quella dell'elemento da scrivere (elemento non visibile)

polinstanziazione evita inferenza – se il soggetto richiedente ha una classificazione che domina quella dell’elemento da inserire ===> polinstanziazione evita negazione di servizio. (attacco SQL INJECTION non l’ho capito, pag 239)

MECCANISMI DI SICUREZZA INFRASTRUTTURALI:

A livello di infrastruttura fisica ci sono degli elementi che consentono di proteggere il SI da attacchi esterni.

Il primo di questi è il firewall cioè insieme di componenti hardware e software il cui obiettivo è collegare una rete fidata con una insicura. Esso controlla, implementando opportune policy di sicurezza, il traffico in entrata e in uscita dalla rete da proteggere con lo scopo di prevenire, rilevare e annullare eventuali attacchi e richieste non autorizzate. Il Firewall deve essere l’unico punto di contatto tra rete interna ed esterna, bloccando tutti i pacchetti non autorizzati (in base alla policy aziendale). Installare un firewall non significa essere sicuri: un

firewall installato e non configurato è inutile. L'aumento del grado di sicurezza portato da un firewall dipende dalla correttezza delle regole specificate, cioè bisogna dargli delle regole precise di selezione dei pacchetti.

Un esempio è l'architettura a due zone come la rete cosiddetta demilitarizzata, DMZ, la quale è la zona tra i due firewall, ovvero tra quello che riceve il traffico della rete esterna e quello a valle del server che filtra i dati verso la rete interna. È un'area in cui di fatto ci possono essere violazioni ma queste poi non hanno alcuna risorsa per compromettere la validità dei dati. (vedi slide 87 sicurezza)

Un altro elemento è l'IDS, cioè l'intrusion detection system che si occupa del processo di monitoraggio degli eventi di un sistema, o di una rete di calcolatori, il cui obiettivo è individuare le intrusioni definite come il tentativo di compromettere la confidenzialità,

l'integrità o la disponibilità del sistema. È caratterizzato da sensori per la raccolta dei dati, che vengono poi analizzati per stabilire se c'è stato o è ancora in atto un attacco, in quest'ultimo caso si attuano poi dei meccanismi automatizzati come report o azioni più complesse. L'IDS si basa sul postulato di osservabilità delle attività di sistema, e sul fatto che le attività intrusive hanno particolari evidenze rispetto a quelle normali. Tra gli IDS, classifichiamo quelli a Misuse Detection, che con tecniche di pattern matching individuano gli attacchi sulla base di quelli già noti, e le tecniche di anomaly detection che invece individua comportamenti anomali negli host o nella rete. Una volta che l'IDS ha verificato un attacco in essere ci sono due tipi di response, quelle active che prevedono l'acquisizione di maggiori informazioni: aumentano il livello di sensitività delle

sorgenti di informazione, modificano l'ambiente bloccando l'attacco in corso (reset connessioni, riconfigurazione di router e firewall) e quelle Passive response che invece notificano che un attacco è in atto all'amministratore del sistema lasciando agli operatori le successive decisioni su quali azioni intraprendere.

Un paradigma di progettazione software è quello realizzato tramite architetture orientate ai servizi (Service Oriented Architecture - SOA). Per servizio si intende una funzionalità di business che può essere invocata dagli utenti tramite una interfaccia di interazione, quest'ultima definisce le operazioni attraverso cui il servizio può essere usato dagli utenti. Un servizio quindi ad esempio può essere un business task oppure una applicazione oppure ancora una risorsa.

Gli elementi di un'architettura a servizi sono:

• Service Requestor: entità che richiede l'esecuzione del servizio

(l'utente che richiede il servizio) - Service Provider: entità che fornisce il servizio

Service Registry: permette di pubblicare le informazioni sui servizi offerti

Un elemento fondamentale di questo tipo di architettura è l'Enterprise Service Bus (ESB) che consente di integrare i servizi di un'azienda gestendo la comunicazione tra le applicazioni. In uno scenario basato sui servizi, ad esempio, per realizzare un'applicazione di e-shopping (amazon) è necessario un servizio per gestire il carrello, un altro per il pagamento, un altro per la ricerca nel catalogo e così via. Le architetture SOA permettono più che di vendere questi servizi come moduli indipendenti, di integrarli tra loro tramite la rete internet, si parla in questo caso di "orchestrazione di servizi", ovvero l'illustrazione di come questi devono essere invocati dall'utente.

Architetture software e loro evoluzione

Il termine architettura software

indica l'insieme delle scelte tecniche ed organizzative che influiscono sullo sviluppo e l'utilizzo di risorse tecnologiche di tipo IT. Si distinguono in architetture centralizzate e distribuite, dove per centralizzate si intende quelle che sono caratterizzate da un unico nodo di elaborazione dove è installato tutto il software che si occupa di elaborare l'informazione, mentre quelle distribuite sono caratterizzate da applicazioni cooperanti installate in più nodi e una base di dati anch'essa distribuita. In termini di evoluzione nel tempo, in prima battuta ci sono state le architetture centralizzate con più terminali che interagivano con un unico nodo, che aveva accesso agli archivi e faceva girare le applicazioni (ERP, CRM...), ma nessun terminale aveva la possibilità di gestire il software in locale. Dagli anni '70 in poi, le nuove tecnologie e l'abbassamento dei costi di hardware e software hanno permesso di spostarsi verso

architettura distribuita con più nodi di elaborazione che possono eseguire applicazioni in locale e collaborano connettendosi tramite una infrastruttura di comunicazione, superando il problema del collo di bottiglia che poteva essere l'elaboratore centrale.

In seguito con l'avvento di Internet (anni '90) la comunicazione tra i vari nodi si è ampliata e ha permesso di sviluppare applicazioni più complesse distribuite su livelli fisici e logici. I livelli logici (chiamati layer) possono essere in generale 3, il primo è quello di presentazione che gestisce l'interazione con l'utente (attraverso una GUI), la seconda è la logica applicativa che si occupa delle funzioni da mettere a disposizione e la terza è la logica di accesso ai dati. Le ultime due sono infatti logiche back end, mentre la prima è front end.

A livello fisico, quindi hardware, i livelli sono detti tier, e ogni livello rappresenta un insieme di machine.

Il meteo che troviamo sui nostri smartphone, in particolare in questo caso, l'interfaccia front-end di presentazione è sul telefono, mentre l'accesso ai dati e la logica applicativa sono su server che si trovano addirittura in UK.