Considerato che un numero sempre maggiore di aziende passa dai metodi di business intelligence tradizionali di query, analisi e reporting dei dati verso il modello altamente iterativo e interattivo di data discovery, con nuovi dati di struttura e volumi più diversi – sta diventando sempre più critica la capacità di caricare, accedere, integrare ed esplorare i dati. E mentre Hadoop si sta conquistando l’accettazione e l’adozione come sistema di data management costruito da zero per essere conveniente, scalabile e capace di lavorare in maniera flessibile con i dati – SQL – cioè lo Structured Query Language, è diventato la chiave per svelare il reale valore di business all’interno della nuova data discovery con un metodo tradizionale.

#datadiscovery John O’Brien, il 2015 è l’anno di #SQL su #Hadoop @techtran
Click To Tweet

Maggiore è il numero degli utenti che possono prendere parte al processo di discovery, maggiore è il valore che può essere realizzato. I pochissimi data scientist in azienda, e anche gli utenti esperti abilitati, possono solo scalfire la superficie del valore di business della discovery, e anche questo alla fine si appiattirà nel corso del tempo. Invece, è bene posizionare questi utenti come gli abilitatori per gli utenti occasionali in azienda che hanno bisogno di accesso (gli scopritori che “sanno quando lo vedono”) e che beneficiano maggiormente dall’avere la capacità di interagire ed esplorare i dati in modo familiare e autosufficiente.

Oggi, l’analista autosufficiente richiede la capacità di accedere ai dati, caricarli su Hadoop, esplorarli in modo iterativo e ricorrere al “fail fast” per scoprire insight nascoste all’interno dei dati. Questo sfida la gestione dei dati e i data warehouse tradizionali principalmente tramite schemi e controlli. Tuttavia, l’utilizzo di SQL per la discovery sfrutta decenni di familiarità, adozione e maturità esistenti all’interno degli strumenti già installati negli ecosistemi tecnologici di oggi. Per esempio, molti dei formati raw dei dati e degli strumenti di visualizzazione intuitivi dei fogli tipo Excel sono fortemente dipendenti da SQL. Pertanto, gli analisti e gli utenti beneficiano immediatamente dall’avere capacità SQL altamente iterative e con elevate prestazioni all’interno di Hadoop.

Sbloccare il valore dei big data nella discovery dipende molto dalla capacità di eseguire SQL, perché è già così pervasivo, accoppiato con funzionalità che hanno prestazioni e capacità. Tuttavia, non tutti i motori SQL sono creati uguali, e maturano tutti in modo diverso, con una storia o un DNA differente. Non solo: alcuni hanno iniziato da poco, mentre altri stanno capitalizzando su anni di funzionalità di database. Ecco perché nelle tre aree seguenti vi sono considerazioni da fare al momento di valutare la potenza di SQL su Hadoop.

#datadiscovery John O’Brien, come valutare la potenza di SQL? @techtran
Click To Tweet

Funzionalità SQL – Al primo posto, c’è la funzionalità SQL. Abbiamo imparato dai database relazionali già esistenti che non tutti gli SQL sono uguali: ce ne sono alcuni specifici per vendor, e mentre i vendor possono eseguire SQL, questi possono essere di numerose versioni, come SQL 99 o SQL 92, oppure di funzioni analitiche successive come ANSI SQL. Se si dispone di strumenti esistenti e report che si intende connettere a Hadoop, non si desidera riscrivere le istruzioni SQL e assicurarsi che funzioneranno in strumenti e le applicazioni esistenti.

La compatibilità con il SQL standardizzato, o con SQL più maturi e avanzati, riduce al minimo le rilavorazioni. E, senza la funzionalità SQL e la maturità, molte funzioni analitiche non saranno in grado di operare in ogni caso. Tenendo presente questo, bisogna guardare alla roadmap del vendor per capire quali funzioni analitiche hanno a disposizione per uno o due anni.

Scalabilità – La seconda area è quella della scalabilità. Con un ampio cluster formato da molti nodi, vi è l’assunto che il motore SQL operi su tutti i nodi del cluster, ma bisogna tuttavia essere consapevoli di alcune limitazioni. Per esempio, se si hanno 100, 500, o migliaia di nodi, forse il motore SQL non è in grado di funzionare su tutto questo ed è limitato per funzionare solo su 16 o 32 nodi alla volta. Tra i primissimi utilizzatori, alcuni hanno isolato aree dei cluster per poter eseguire SQL su motori Hadoop, realizzando di conseguenza un’architettura a più livelli in singoli cluster.

Inoltre, bisogna essere consapevoli della duplicazione di dati determinata dal formato dei file di dati all’interno di HDFS. I dati sono all’interno di un file aperto, quale un ORC (Optimized Row-Column) o un Parquet, o richiedono l’estrazione da questi file in un formato di file proprietario che non può essere letto da altri motori all’interno di Hadoop? Quindi attenzione alla duplicazione di dati al fine di alimentare il motore SQL su Hadoop.

#datadiscovery John O’Brien, SQL è il linguaggio della data discovery @techtran
Click To Tweet

Velocità – Infine, è tutta una questione di velocità. La velocità ha importanza, soprattutto in termini di tempo di risposta, e ancor di più dalla prospettiva della discovery, dove l’obiettivo è quello di scoprire in fretta attraverso un “fail fast” iterativo. Se si sa che si incontreranno fallimenti 99 volte prima di trovare il primo insight, si cerca di spostarsi attraverso quelle 99 iterazioni il più rapidamente possibile. Attendere 700 secondi per la risposta a una query o per un processo batch può essere una forma dolorosa di analisi, nella quale è possibile scoprire i propri livelli di pazienza prima di qualsiasi approfondimento dei dati.

Pensare a lungo termine – Quando si sceglie un SQL su motore Hadoop, bisogna prendere in considerazione, con una visione ampia, le proprie strategie e architetture dati, assicurandosi che siano allineate. L’architettura per SQL su Hadoop continuerà a evolversi: è già passata dal batch-oriented Hive su MapReduce in Hadoop versione 1 all’Hadoop versione 2 dell’anno scorso, che ha aggiunto i benefici dei file ORC con Hive e TEZ per operare su YARN nelle query vettorializzate che ha portato notevoli incrementi di prestazioni a Hive 13. Oggi, vediamo “SQL architetturale”, con Hive e TEZ in esecuzione su YARN all’interno dei cluster, e possiamo anche iniziare a portare altri motori eseguiti direttamente con HDFS. L’architettura è un elemento di differenziazione tra SQL sui motori di Hadoop che sono già compatibili con YARN e quelli che incrementano le prestazioni andando direttamente con HDFS e cercando compatibilità in strategie a lungo termine.

In ultima analisi, SQL sta diventando sempre più parte della storia dell’unificazione delle piattaforme dati. Grazie a SQL, si possono mettere insieme i dati aziendali, gli analytics di fascia alta e i set di big data che vivono in Hadoop, potendo quindi iniziare a lavorare con tutti questi attraverso un linguaggio unificante.

John O’Brien

La combinazione dei diversi ruoli che ha svolto come professionista, consulente e vendor, rendono unico e originale il suo punto di vista. Con 25 anni di esperienza nei settori Data Warehousing e come esperto riconosciuto nel settore BI, ha pubblicato numerosi articoli ed è intervenuto come speaker in importanti conferenze negli Stati Uniti e in Europa. Oggi, John O’Brien svolge attività di ricerca e offre servizi di strategic advisory, per guidare le aziende verso la nuova generazione dell’Information Management.

John O’Brien presenterà a Roma per Technology Transfer i seminari “Data Discovery in Action” nei giorni 18 e 19 novembre 2015 e “Modern Data Visualizations and Story Telling” il 20 novembre 2015.

L'articolo Ecco perché SQL è il linguaggio della data discovery proviene da Data Manager Online.

Questo è solo uno dei numerosi problemi emersi da una recente indagine tra i DBA e gli sviluppatori SQL eseguita da Kroll Ontrack. Cancellazioni accidentali (35%), errori di sviluppo (28%), sovrascritture effettuate per errore (24%) e crash di sistema (13%): il tempo speso nel ripristino di database SQL viene sottratto ai DBA quando potrebbero invece impiegarlo per affrontare altre criticità.

Inoltre, la ricerca di Kroll Ontrack dimostra che tra gli intervistati le richieste di ripristino dei dati da ambienti di sviluppo e test è quasi il doppio rispetto ad ambienti di produzione: un risultato logico se si considera che gli sviluppatori sono continuamente attivi nel provare nuove procedure in ambienti di sviluppo, quindi meno stabili.

Infatti, su base mensile, il 50% degli intervistati gestisce tra 1 e 5 richieste di restore da ambienti di sviluppo e test, quasi il 20% dalle 6 alle 10 richieste, mentre il 15% deve affrontarne più di dieci al mese. I report di una precedente ricerca di Kroll Ontrack hanno evidenziato che il restore di tabelle di database richiede più di un’ora per il completamento. Sfruttare tecnologie efficienti per ridurre il tempo di ripristino è la chiave per risparmiare tempo e denaro.

«Non è un segreto che i dati ospitati all’interno di database SQL siano di fondamentale importanza per il successo del business di un’azienda“, afferma Tom McCaffrey, Director of Enterprise Solutions di Kroll Ontrack. “Come tale, ogni danneggiamento al database è intrinsecamente costoso e crea stress sui DBA che sono tenuti a eseguire un recupero efficiente. Ontrack PowerControls per SQL offre ai DBA la possibilità del restore granulare di tabelle SQL in pochi secondi, non ore, senza dover ripristinare l’intero database o utilizzare SQL per leggere i backup“.

Supporto ai backup compressi

Nella sua versione più recente, Ontrack PowerControls 8.1 per SQL aggiunge funzionalità per supportare backup compressi Microsoft SQL Server in aggiunta ai backup nativi e agli storage tier snapshots, dando agli amministratori IT la possibilità di aprire e ripristinare le tabelle dai backup compressi.

“I backup compressi diventato ampiamente disponibili con SQL Server 2008 R2 e sono usati dalla maggioranza delle aziende“, dichiara Sascha Lorenz, Microsoft MVP. “Oltre all’ovvio beneficio della riduzione dello spazio di archiviazione, i backup compressi hanno guadagnato in popolarità perché il backup può essere fatto più velocemente e il ripristino è più rapido”.

Ontrack PowerControls consente inoltre ai DBA di affrontare al meglio i periodici restore di tabelle SQL attraverso:

Funzionalità Drag and Drop: facile ripristino di singole tabelle da backup nativi di SQL o storage tier snapshots nell’ambiente desiderato, eliminando la necessità di ripristinare l’intero database.

Validazione prima del restore: l’anteprima del contenuto della tabella permette di verificare che i dati siano corretti prima di eseguire il ripristino.

Semplificazione dei processi: elimina l’esigenza di T-SQL o script PowerShell quando si copia una tabella da un backup o snapshot.

L'articolo Il 90% di perdita dati da SQL è per errore umano proviene da Data Manager Online.

Una nuova estensione dello strumento per il restore dei dati di Kroll Ontrack affronta uno dei più grossi grattacapi con cui hanno a che fare i Database Administrator (DBA) in SQL.
Kroll Ontrack annuncia l’ampliamento della propria pluripremiata suite Ontrack PowerControls come tool di ricerca e restore granulare per Microsoft SQL Server. Il tool è una risposta diretta al feedback dei clienti, i quali sostengono che ripristinare tabelle SQL da backup o snapshots sia una richiesta frequente, che può causare diverse ore di interruzione al giorno. Le nuove funzionalità possono ridurre in modo significativo il tempo dedicato al ripristino di queste tabelle, letteralmente da ore a minuti.

Una ricerca condotta da Kroll Ontrack ha rivelato che il 64% degli amministratori di database (DBA) intervistati riferisce di regolari eventi di ripristino SQL ogni mese come risultato di tabelle perse, mancanza di dati in righe o colonne o tabelle necessarie per finalità di sviluppo o di analisi. Il 39% riporta da una a cinque richieste di ripristino SQL al mese e un ulteriore 25% ne cita più di 6. Inoltre, quando è stato chiesto loro quanto tempo fosse solitamente necessario per ripristinare una tabella da un database di SQL Server, il 52% ha affermato più di un’ora.

“SQL è alla base di molte applicazioni aziendali. Se poi ad essere inutilizzabile è un’applicazione SQL critica per il fatturato dell’organizzazione, è piuttosto comune trovare il CIO che, appena dietro alle spalle del DBA, spera in un rapido lavoro di ripristino poiché il fermo può costare all’azienda migliaia di euro.”, dichiara Paolo Salin, Country Director di Kroll Ontrack Italia. “Oggigiorno, il processo di restore richiede in genere ore – tempistica determinata dalla dimensione del database insieme con gli attuali metodi di restore di SQL Server che richiedono il ripristino dell’intero database e la presenza del server SQL durante la procedura – anche se è necessario il restore di una sola tabella. Ontrack PowerControls rivoluziona il restore come fino ad oggi conosciuto dai DBA, consentendo loro di ripristinare in modo granulare tabelle SQL, senza dover ripristinare l’intero database o utilizzare SQL per leggere i backup”.

“Tabelle perse o mancanti rappresentano un aspetto fin troppo familiare del mio lavoro, ma sono molto più impegnative di quanto dovrebbero essere. Devo prima trovare il backup richiesto, quindi individuare un server che disponga di spazio sufficiente e infine ripristinare l’intero database anche solo per una tabella”, afferma James Dorame, database system manager, Questar Assessment Inc. “Ontrack PowerControls mi permette di risparmiare ore di tempo a confronto con i metodi nativi di restore, consentendomi di focalizzarmi su un elenco di cose da fare già pianificato e su iniziative strategiche di business.”

In particolare, Ontrack PowerControls per SQL consente ai DBA di affrontare rapidamente e facilmente regolari richieste di ripristino di tabelle SQL attraverso la seguenti caratteristiche:

• Drag and drop di singole tabelle da backup nativi di SQL Server o storage tier snapshots all’ambiente desiderato, eliminando la necessità di ripristinare l’intero database
• Anteprima del contenuto della tabella per verificarne la versione prima di eseguire il ripristino
• Restore di una tabella senza la necessità di T-SQL o PowerShell scripting

“Riceviamo fino a tre richieste al giorno per recuperare tabelle perse”, dichiara Mark Classen, consulente DBA. “Se avessimo questo strumento, potremmo facilmente gestire tali situazioni, recuperando le tabelle per i dipartimenti che ne fanno richiesta. Senza Ontrack PowerControls non ci resta che dire ‘no, non possiamo farlo.’ “

L'articolo Kroll Ontrack lancia Ontrack PowerControls per SQL proviene da Data Manager Online.

Ieri sera qualcuno si è accorto che qualcosa sul sito del Wall Street Journal non andava. Questo qualcuno è l’azienda di sicurezza IntelCrawll che ha avvisato l’agenzi di stampa Dow Jones Newswire, di cui il Journal fa parte, di una possibile intrusione informatica nel servizio di infografiche della testata. Sembrerebbe che all’interno dei server sia entrato un hacker conosciuto come “W0RM” che, su Twitter, sostiene di aver rubato le informazioni degli utenti e le credenziali di accesso al sito, utili per modificare articoli, aggiungere nuovi contenuti e addirittura nascondere nelle pagine web minacce e virus. L’hacker ha inoltre messo in vendita l’intero archivio sottratto per 1 bitcoin, attraverso il suo “negozio” di vendita di exploit w0rm.in.

Wall Street Journal hackerato: cosa è successo

Secondo Andrew Komarov, CEO di IntelCrawl, l’hacker sarebbe lo stesso che in precedenti occasioni aveva usato i nickname “Rev0lver” e “Hash”; arriverebbe dalla Russia e già durante lo scorso dicembre avrebbe tentato di accedere ai server della BBC. Alle 23.30 di ieri sera (ora italiana) l’hacker ha postato una schermata su Twitter che mostra i dati di accesso dell’admin di sistema al sito violato, come prova del suo lavoro. Per questo l’agenzia Dow Jones ha messo offline diverse volte i server, per isolare il problema e prevenire intrusioni future nel sistema. Un portavoce dell’azienda ha dichiarato: “A questo punto non abbiamo evidenza che vi siano state conseguenze per i clienti e per i loro dati”. Tuttavia Komarov ha spiegato come la IntelCrawl abbia rilevato una vulnerabilità SQL nel sito del Wall Street Journal che avrebbe reso possibile accedere ad ogni database hostato sugli stessi server su cui si appoggia la testata. A quanto pare IntelCrawl segue da tempo le mosse di “W0RM”, tanto che sono riusciti a risalire a lui come l’artefice di una serie di altre violazioni ai danni dei siti di testate internazionali tra cui la BBC e Vice Media, poi patchati per tappare le vulnerabilità di sicurezza riscontrate.

L'articolo Wall Street Journal hackerato: archivio in vendita per 1 bitcoin proviene da Data Manager Online.

Senza dubbio i big data sono una delle tendenze di spicco nel settore IT. Come noto, i big data comportano la memorizzazione, la gestione e l’analisi di enormi quantità di dati. Oggi, le aziende possono scegliere come memorizzare i dati tra le soluzioni basate su SQL o quelle che si basano su NoSQL, come Hadoop, Cassandra o MongoDB. Soprattutto questo secondo gruppo ha riscosso molta attenzione negli ultimi anni. E recentemente sono stati resi disponibili molti prodotti che “avvolgono” un sistema NoSQL in uno strato di SQL: in altre parole, i sistemi NoSQL si stanno trasformando in sistemi SQL. Ma quali sono le ragioni di questa tendenza?

È difficile dare una definizione dei sistemi NoSQL, in quanto sono tutti diversi e hanno in comune solo due cose. In primo luogo, sono stati classificati in un gruppo chiamato NoSQL, e in secondo luogo hanno tutti un’architettura MPP (Massively Parallel Processor) altamente scalabile che permette di distribuire l’elaborazione e lo storage in centinaia di nodi. La loro architettura interna è ideale per scalare in modalità scale-out, cioè in senso orizzontale, mentre i database SQL classici hanno un’architettura progettata per lo scale-up, ovvero in senso verticale. Ma è qui che finisce ogni somiglianza.

Caratteristiche fondamentali

I prodotti NoSQL sono molto diversi dai sistemi SQL, in quanto non organizzano i propri dati in tabelle piatte costituite da colonne, non supportano l’integrità dei dati, non sono limitate a strutture relazionali piatte ma consentono le strutture gerarchiche nei dati, e non supportano un linguaggio di alto livello come SQL, ma solo API e linguaggi di basso livello. Questi diversi concetti di database e di interfacce sono stati implementati per ottime ragioni: infatti, possono essere utilizzati in ambiti big data nei quali le esigenze di storage e di elaborazione sono estremamente elevate.

Tuttavia, quasi tutti gli strumenti più diffusi per il reporting e le analisi esigono che i dati siano organizzati in tabelle SQL, e si aspettano un’interfaccia SQL. Ma soprattutto non funzionano con NoSQL. Inoltre, a causa delle API di basso livello supportate, la produttività è inferiore a quella di SQL e, infine, non tutti gli sviluppatori (in particolare all’interno di reparti BI) hanno esperienza con la programmazione in linguaggi come Java o Python.

Per questi motivi, per utilizzare i noti strumenti di reporting e di analisi unitamente a NoSQL bisogna prima copiare i dati da un sistema NoSQL a uno SQL. Come si può immaginare, questo processo di copia richiede tempo, e conservare per due volte (unicamente per ottenere un’interfaccia SQL) grandi quantità di dati è costoso. È meglio perciò se i dati rimangono all’interno del sistema NoSQL e vi si accede tramite un’interfaccia SQL.

La buona notizia

Sempre più soluzioni si sono rese disponibili per una “SQLizzazione” di NoSQL, con strumenti che consentono alle applicazioni di accedere ai dati memorizzati nei sistemi NoSQL utilizzando SQL. Le soluzioni di SQLizzazione possono essere classificate così:

• Driver dedicato: molte soluzioni offrono un’interfaccia SQL su uno o più sistemi NoSQL. Alcuni consentono inoltre di accedere a fonti dati SQL e possono federare i dati archiviati in più fonti dati. Questi driver trasformano le richieste SQL in arrivo nei linguaggi supportati dal sistema NoSQL, nascondendo la complessità dei linguaggi di basso livello. Tra gli esempi vi sono Apache Hive, Cassandra CQL, Cloudera Impala, DataDirect Cloud, Facebook Presto, Hortonworks Stinger, IBM BigSQL, MapR Drill, Quest Toad for Cloud Databases e Salesforce Phoenix.
• Server di virtualizzazione dati: i server di virtualizzazione dati offrono caratteristiche paragonabili alla traduzione da SQL a NoSQL vista poco fa, ma con tre principali differenze. I server di virtualizzazione dati supportano funzioni più potenti di ottimizzazione delle query quando si accede alle fonti dati, hanno tecnologie di federazione più mature e offrono funzionalità di sicurezza dei dati e ambienti di progettazione. Tra gli esempi, vi sono Cisco/Composite Information Server, Denodo Platform, Informatica IDS, RedHat JBoss Data Virtualization e Stone Bond Enterprise Enabler Virtuoso.
• Database server SQL: alcuni dei database server SQL danno una scelta agli sviluppatori, permettendo di memorizzare le tabelle SQL nel database nativo o in un sistema NoSQL come Hadoop, e il luogo effettivo in cui i dati vengono memorizzati è nascosto alle applicazioni. Gli esempi sono Actian Paraccell, EMC Greenplum UAP, Hadapt, Microsoft Polybase e il database Teradata Aster.

Bisogna però notare che la “SQLizzazione” dei database NoSQL non è così semplice come potrebbe a prima vista sembrare, soprattutto perché le performance rimangono un aspetto molto rilevante. È per questo che tali soluzioni devono affrontare alcune questioni, tra le quali vi sono queste:

• Alcuni dei dati nei sistemi NoSQL sono privi di schema: come può l’interfaccia SQL trasformare questi dati senza schema in dati relazionali con uno schema?
• La maggior parte dei sistemi NoSQL permettono che i record appartenenti alla stessa tabella abbiano diverse serie di colonne, mentre questo concetto non è supportato da SQL.
• Molti sistemi NoSQL supportano costrutti non relazionali come le strutture gerarchiche. Nella terminologia relazionale, questi sarebbero chiamati tabelle nidificate o tabelle NF2 (Non-first normal form). In qualche modo le soluzioni “SQLizzate” devono appiattire queste strutture gerarchiche in strutture relazionali piatte.
• Il join dei dati in SQL è una cosa molto comune da fare. Pertanto, i database server SQL sono sovraccarichi di funzioni per eseguire rapidamente il join. Ma molti sistemi NoSQL non sono rapidi nella funzione join, e preferiscono che i dati siano memorizzati in una qualche maniera de-normalizzata per ridurre al minimo la necessità di effettuare il join. Sarà quindi una vera sfida per le soluzioni di SQLizzazione eseguire rapidamente i join SQL.

Conclusione

La “SQLizzazione” di NoSQL è iniziata e continuerà a evolversi. Quest’anno ci si aspetta che vengano rilasciati nuovi prodotti e vengano rese disponibili versioni rinnovate di quelli esistenti. Si tratta di un fatto positivo in quanto le aziende sono interessate a NoSQL non perché non amano SQL, ma perché hanno bisogno della scalabilità e delle prestazioni di NoSQL. Però vogliono anche la produttività e la facilità di manutenzione di SQL, e la SQLizzazione offrirà il meglio dei due mondi: le prestazioni del NoSQL e la produttività di SQL.

Rick F. van der Lans

Analista indipendente, consulente, autore e docente specializzato in data warehousing, business intelligence e database. Amministratore delegato di R20/Consultancy, van der Lans è un conferenziere di fama internazionale ed è autore di numerosi white paper. Le sue opere più note, tra cui “Introduction to SQL” e “The SQL Guide to Oracle”, sono stati tradotti in numerose lingue e hanno venduto oltre 100mils copie. La sua pubblicazione più recente è “Data Virtualization for Business Intelligence Systems”.

Rick F. van der Lans presenterà a Roma per Technology Transfer i seminari: “La nuova tecnologia database” il 3 giugno 2014 e “Lean Data e Application Integration usando la Data Virtualization” il 4 giugno 2014.

L'articolo Se il NoSQL diventa SQL proviene da Data Manager Online.

Avete presente la classica dicotomia tra hacker e cracker? Bene, dimenticatela o almeno provateci. Pare infatti che il remunerativo lavoro di bucare sistemi di sicurezza, password e dati sensibili sia sempre di più un vero e proprio lavoro al quale molti giovani, soprattutto nord-europei, puntano. L’hacking come business prevede una forte convergenza tra attori e ruoli che, negli ultimi tempi, tendono a convergere, riducendo sempre di più la linea di separazione (spesso etica) tra l’hacker e il cracker.

Manuale per piccoli hacker

L’azienda Stonesoft, attiva dal 1990 su software di sicurezza informatica per medie e grandi imprese dei settori finance, PA, sanità e telco, ha organizzato un vero e proprio laboratorio per far testare con mano alcune delle azioni all’ordine del giorno per gli hacker in tutto il mondo, forte del rinnovato fregio ricevuto da NSS Labs. “Si pensa che le migliori password siano fatte da nomi strani, numeri e lunghe almeno 8 caratteri – ci dice Otto Airamo, Senior Network Security Specialist di Stonesoft, che è arrivato dalla Finlandia assieme al collega Olli-Pekka “Opi” Niemi, Head of the Vulnerability Analysis Group di Stonesoft – in realtà basterebbe utilizzare una password di 12 caratteri semplici ma convertiti in testo ASCII così da rendere il tutto ben più difficile da decriptare“. Spesso si consiglia di utilizzare password diverse per piattaforme differenti, un concettoi che si basa su un motivo basilare: i siti web hanno politiche di privacy diverse per cui uno potrebbe conservare solo il tuo nome, un altro anche il tuo indirizzo ed un terzo la carta di credito; da qui il buon consiglio di avere una password “unica” che non permetta con un solo hack di ottenere praticamente tutto sulla nostra vita.

Liste di password

“Gli hacker hanno fogli di testo lunghissimi, dove sono conservate le password più utilizzate per le nazioni principali – continua Otto – è evidente che un italiano sarà spinto maggiormente ad utilizzare certi termini, diversi da quello finlandese ma simili all’inglese, lingua oramai accettata come universale anche sul web“. Ma perchè fare l’hacker oggi è così tanto di moda? “C’è un intero mercato (blank market) dietro il traffico di dati personali – spiega Opi – che oscilla da qualche decina di dollari a centinaia. Tutto dipende dal mercato e dall’utente i cui dati sono stati rubati“. Il metodo migliore per rubare le password è quello della “return page” attraverso una “SQL Injection“. Quando si visita un sito preferito, al quale siamo registrati, può capitare di imbattersi in un messaggio d’errore in calce al quale si trova il link per tornare alla pagina principale. La pagine di errore altro non è che un metodo per gli hacker di ricevere le prime informazioni sull’account, tra cui il nome utente e l’ID assegnato dalla piattaforma. Con un tool online (come mostrato nel video seguente) non sarà complicato ricevere la password dell’utente specifico (tra la lista di tutte quelle del sito) e decriptarla in pochi secondi.

Centrali sotto attacco

Uno dei virus che ha fatto più discutere negli ultimi tempi è sicuramente Stuxnet, la minaccia che Stati Uniti e Israele hanno lanciato verso le centrali di gestione critica dell’Iran per controllarne mosse e obiettivi. Otto e Opi ci mostrano quanto sia paurosamente semplice varcare i limiti di una centrale nucleare media, passando per le reti interne fino a raggiungere il cuore centrale (come nel video sotto). “Il problema dei sistemi SCADA – spiega Otto – è che chi li gestisce non è pronto ad affrontare una minacca in atto. Ci sono tre bad practices che vengono messe in atto: il turarsi le orecchie per far finta di non sapere nulla, lo spostamento fisico di reti e server, il ricorrere alla virtualizzazione di tutti i processi“. Ovviamente nessuna delle tre tecniche può bloccare un hacker esperto che in qualche ora può causare danni rilevanti alla centrale e ai cittadini serviti. In questo processo vengono utilizzati due software specifici online come Nmap, che permette di vedere quali computer ci sono nella rete e i loro sistemi operativi e  Metasploit, per rilevare primarie falle sui computer individuati.

Il panorama hacking aziendale

La sensazione è che davvero nulla sia precluso agli hacker esperti, sia che agiscano in gruppo che da soli. “Spesso aziende medio-grandi non si accorgono di quanti problemi ci siano nelle loro infrastrutture – ha sottolineato Emilio Turani, Country Manager per l’Italia, la Grecia, la Turchia e la Svizzera di Stonesoft – anche se le software house sono prontissime a lanciare soluzioni scudo per proteggersi, gli hacker sono anche più svelti nel trovare falle e produrre contro-software per rilevarle“. Un aiuto per capire dove è possibile migliorare i propri sistemi arriva da Evader 2.01, il tool per rilevare le Tecniche di Evasione Avanzata (AET) che permette alle aziende di lanciare manualmente o automaticamente una varietà di attacchi per provare le capacità di sicurezza delle reti e dispositivi aziendali in uso. Ulteriore linfa arriva dalla prossima acquisizione di Stonesoft da parte di McAfee che dovrebbe concludersi per 389 milioni di dollari, un’operazione tesa a potenziare il portafoglio di soluzioni di network security del fornitore statunitense grazie alla tecnologia di next generation firewall del fornitore finlandese.

L'articolo Hack the Lab: così due ragazzi possono comandare il mondo proviene da Data Manager Online.

by Chris Date

Sareste disposti a vivere in un grattacielo costruito ignorando i principi architetturali fondamentali? Sareste disposti a gestire il vostro business con un database realizzato ignorando le regole e i principi fondamentali del database computing? La risposta alle prime due domande è scontata. E riguardo alla terza domanda? La risposta dovrebbe essere, ovviamente, negativa. Se – però – si deve giudicare da quanto accade, ci si accorge che, spesso, si risponde implicitamente con un sì. Come mai? Forse, semplicemente per il fatto che molte persone non sono al corrente dell’esistenza di una solida teoria scientifica. È sufficiente riflettere su alcune delle seguenti – e errate – affermazioni per renderci conto di quanto sia vero quello che abbiamo appena detto.

(Le affermazioni sono tratte dal sito web di Fabian Pascal, www.dbdebunk.com. Sono state volontariamente omesse alcune fonti per non rilevare il nome degli autori e il testo è stato modificato per renderlo più comprensibile).

«Ho già creato un database secondo la logica Entity-Attribute-Value»

Così facendo gran parte del modello logico è rappresentato in una forma dati e non come schema. In questo modo qualunque cambiamento al modello logico può avvenire senza modificare lo schema. Non solo, ma anche le stored procedure, se scritte correttamente, non devono essere cambiate. Le controindicazioni? Si deve fare uso di un codice SQL molto complesso. Ho utilizzato questa logica nei confronti di un cliente che non aveva una chiara comprensione dei propri requisiti e domandava di avere un’applicazione funzionante con una deadline precisa.

«Ritengo che i database siano dei semplici archivi, dedicati a gestire dati, non la logica di business…» 

Facciamo in modo che il database sia il più semplice possibile e che invece sia l’applicazione a essere smart. Dopotutto, è l’applicazione a riflettere un processo di business mentre il database è puro storage, uno strumento di supporto all’applicazione.

«Il problema dei database relazionali è la necessità di adattare la struttura di tabella ogni qualvolta si aggiungono dati…» 

Con RDF si possono riversare dati in uno store multiplo e lavorare su di essi immediatamente. Si tratta di un metodo molto più agile.

«SQL è inadeguato per gestire il modello relazionale poiché non permette di esprimere relazioni diverse da quelle definite dalla tabella» 

Non è questa una limitazione del modello relazionale stesso? Credo che solo il modello entity-relationship possa fare delle distinzioni tra relazioni e dati. Una volta che si converte il modello in un modello di dati relazionali si perde quella capacità. Quanto meno questo è ciò che abbiamo appreso durante i corsi universitari sul database.

«Sono un utente Microsoft Access alle prime armi. Di solito non utilizzo chiavi primarie» 

Da quanto ho letto la chiave primaria viene principalmente usata per velocizzare le operazioni di ricerca. Al momento uso solo due piccole tabelle che contengono un comune record ID. Effettuo query su queste tabelle e non mi risulta che vi siano errori. Da ciò che ho potuto costatare, riesco a ottenere dei risultati corretti. È importante utilizzare la chiave primaria o è soltanto qualcosa che sarebbe bene avere quando si lavora su grandi database?

Risposta: «La definizione di una chiave primaria non è mai necessaria, nemmeno in un grande database»

 I vantaggi di una chiave primaria consistono nell’avere la sicurezza che il campo contenga solo valori unici. Questo evita la duplicazione di record. Access garantirà che la chiave primaria contenga un valore in modo tale che si possa avere una identificazione unica del record.

«I database relazionali sono essenzialmente matrici a due dimensioni con puntatori e fogli elettronici di alto livello» 

E’ molto probabile che database XML o a oggetti consentano un adattamento maggiore nei confronti di architetture e modelli dati con cui si lavora quotidianamente: sono più flessibili e personalizzabili. Si è in grado di adottare principi di programmazione estrema, così come aggiungere nuovi campi, connettersi ad altri sistemi ed essere focalizzati sul modello dati e sul progetto e non sul modello del database e del possibile modello che meglio si adatta a quel database. Operazioni import-export da RDBMS sono immediate. Questi ultimi sono creati per lavorare in real-time e trarre un reale vantaggio da disegno e manutenzione di OODBMS preservando l’atomicità e i tool relazionali correnti senza sacrificare la qualità dei dati.

«Non ho mai avuto necessità che mi fosse spiegato il design di un database. Era così intuitivo, così ovvio…» 

on concepisco l’idea che possa esistere una diversa struttura di database. Non vedo l’ora di imparare qualcosa di nuovo i cui contenuti mi sono ancora del tutto estranei.

Risposta: «Dimenticate tutto ciò che sapete sui modelli dati: questa è la prima regola del data warehouse» 

Per poter realizzare velocemente degli ottimi report, senza dover necessariamente contare su un team di matematici, dobbiamo fare una cosa triviale quanto insignificante. Fare tabula rasa della mentalità che considera il database come il cuore di tutto ciò che facciamo. Citando un sito web, possiamo dire di smettere di pensare il database in termini architetturali! Le applicazioni associate direttamente al database sono costose da sviluppare e manutenere. Sebbene una volta fossero considerate lo stato dell’arte sono oggi notoriamente poco sofisticate e poco adattabili.

Conclusioni

 Bene, potrei spendere un sacco di tempo per contraddire tutte queste affermazioni, ma non credo sia poi così necessario. Penso che il messaggio sia sufficientemente chiaro e semplice: esiste una ignoranza diffusa. Ho un altro fatto da raccontare e che rende più forte la mia opinione. È una lettera pubblicata sul numero del luglio 2011 di Communication of ACM (Volume 54, n. 7). Nota: l’autore fa riferimento, nello specifico, a object/relational mapping e a sistemi NoSQL (un altro termine di moda privo di senso), tuttavia sono considerazioni che possono essere estese ad ambiti più ampi. Nella lettera si legge: “Object Relational Mapping e sistemi NoSQL tentano di risolvere (attraverso mezzi tecnici) un problema non tecnico. La difficoltà di molte persone nel padroneggiare il modello relazionale e, quindi, di trarre vantaggio dalla consistenza dei dati e dalla logica inferenziale è un problema di conoscenza. Invece di sfruttare in modo adeguato e chiedere ai vendor DBMS più funzionalità relazionali, molti cercano di evitarlo e sostituirlo, invocando un ritorno ai fragili e inaffidabili sistemi degli Anni 70”.

La verità è che esiste una conoscenza scientifica per risolvere il problema del database, ma non è messa in pratica. Molte persone evitano deliberatamente di applicare la teoria, come se questa non avesse possibilità di essere tradotta nel mondo reale (non rompetemi le scatole con disquisizioni filosofiche, sono una persona molto pratica!). La mia idea è tutto l’opposto. Se qualcosa non è fondato su una solida teoria, è facile che non sia praticabile.

Vorrei chiudere questo articolo citando Leonardo da Vinci e quanto scrisse a proposito cinquecento anni fa: “Coloro che non coniugano la pratica con la teoria sono come un comandante che sale sulla nave senza timone o compasso. Viaggiano senza conoscere in quale direzione stanno andando. La pratica dovrebbe invece sempre poggiare su una forte base teorica”. Leonardo aveva ragione.

Chris Date

Chris Date è uno dei nomi più importanti nell’intero campo del computing ed è stato inserito nel 2004 nella Computing Industry Hall of Fame. Autore, presentatore, ricercatore e consulente indipendente specializzato nella tecnologia del database relazionale. È uno dei protagonisti nell’intero campo del computing. Il suo libro “An Introduction to Database Systems: Vol. I”, rappresenta il testo standard in questo campo, ha venduto più di 780mila copie in tutto il mondo ed è usato come libro di testo in centinaia di università in tutto il mondo. È autore di molti autorevoli libri sulla tecnologia database, includendo i più recenti: “Databases, Types, and the Relational Model – The Third Manifesto” (con Hugh Darwen, Apress, 2006) – “Date on Database: Writings 2000-2006” (Addison-Wesley, 2006) – “Logic and Databases: The Roots of Relational Theory” (Apress, 2007) – “The Relational Database Dictionary, Extended Edition” (Apress 2008) –

“A Relational Approach to SQL: How to Wtite Correct SQL and Know it” (O’Reilly, 2008) – 

Chris Date ha la grandissima abilità di comunicare soggetti tecnici complessi in maniera chiara e comprensibile.

Nota:

Chris Date tiene regolarmente in Italia seminari per la Technology Transfer.

L'articolo Leonardo da Vinci aveva ragione! proviene da Data Manager Online.

Chris Date: «Si va verso un modello transrelazionale che non sostituisce il modello relazionale, ma lo integra e lo completa»

Ne abbiamo parlato con Chris Date, presente a Roma per il corso SQL e Teoria Relazionale: come scrivere un corretto SQL, organizzato dalla Technology Transfer (www.technologytransfer.it).

Data Manager: Il DB è la fondamenta su cui poggiano i sistemi informativi, no DB no IT, a che punto siamo con lo stato dell’arte?

Chris Date: Attualmente non seguo più tanto quelle che sono le tendenze industriali del settore, tuttavia posso dire che condivido la definizione che il database è il fondamento dei sistemi informatici, sulla seconda domanda, sono nuovamente d’accordo: senza un database non ci possono essere sistemi informatici. Sulla terza domanda, sicuramente la mia speranza è che continui a progredire e a evolversi anche in futuro, in effetti esistono tanti database, ma molti sono fatti male, hanno cose che non dovrebbero avere e ne hanno altre che sono addirittura sbagliate, quindi è opportuno rettificare tutto ciò.

Quali sono quelli fatti bene e quali quelli male?

Con alcuni colleghi stiamo lavorando da qualche anno e abbiamo messo a punto quello che è noto come il “Terzo Manifesto”. Abbiamo sviluppato, insieme ai principali vendor oggi attivi sul mercato, alcuni prodotti, ma questi sono ancora solo a livello di prototipo.

Lo scopo era quello di cercare di correggere molti degli errori contenuti nell’SQL. Ted Codd ha inventato e sviluppato, com’è noto, il modello relazionale e questo è stato sicuramente un risultato di grande portata però, purtroppo, la migliore implementazione di questo modello relazionale è l’SQL che oggi contiene un’infinità di errori. Questo linguaggio ha avuto successo solo per motivi economici e non per ragioni tecniche.

Qualche anno fa ho avuto un rapporto di collaborazione e consulenza con una piccola società che aveva messo a punto un nuovo modello straordinario che si chiama commercialmente “modello relazionale transrelazionale”, in sostanza si basa sul principio che il modello relazionale viene tramutato in fase di memorizzazione. Quello che vorrei precisare è che questo modello transrelazionale non sostituisce quello relazionale, ma lo integra e lo completa e in effetti è molto diverso da Oracle e da DB2 e offre tre importanti vantaggi: in primo luogo migliora notevolmente le performance, in secondo luogo migliora di molto la gestione quindi l’amministrazione e, in terzo luogo, è in grado di risolvere dei problemi che non sono stati risolti, per esempio permette di fare il join di centinaia di tabelle, cosa che è impossibile con il relazionale.

Il modello relazionale è il passato o anche il futuro?

In effetti devo dire che ogni tanto arriva qualcuno che dice di possedere un modello relazionale infinitamente migliore, io penso che se una persona ha sviluppato una nuova tecnologia che possiamo chiamare per esempio B a sostituzione della tecnologia cosiddetta A, in primo luogo questa persona deve capire bene e conoscere approfonditamente la tecnologia A e in secondo luogo mi deve dimostrare che la sua tecnologia B innovativa è in grado di risolvere quei problemi che non è in grado di risolvere la tecnologia A. A me non è mai capitato di trovare una persona che sia stata in grado di dimostrarmi questo.

Le aziende hanno capito la reale potenzialità di questo strumento?

No, ritengo che le aziende non abbiano capito davvero quello che è il vero potenziale di queste tecnologie. Ci sono degli aspetti sia positivi che negativi del modello relazionale, ma direi che il potenziale non è ben capito a causa delle implementazioni che sono molto carenti e insufficienti. Ciononostante c’è anche un esempio positivo; alla radio ascoltavo un’intervista con un importante economista che stava analizzando la difficile situazione economica negli Stati Uniti e aveva scoperto che con un database relazionale poteva confrontare dei risultati e dei fattori economici relativamente complessi: oggi dunque importanti attori della scena internazionale capiscono l’importante valore che può offrire il modello relazionale.

Progetti futuri?

Un fattore su cui sto lavorando attualmente riguarda il famoso problema dell’aggiornamento delle viste, non c’è nessun prodotto, infatti, che abbia svolto questa funzione in modo efficiente e abbiamo bisogno di teoria anche per questo.

——————————–

Chris Date. Autore, presentatore, ricercatore e consulente indipendente specializzato nella tecnologia del database relazionale. Il suo libro An Introduction to Database Systems: Vol. I ha venduto più di 850mila copie ed è usato come libro di testo in centinaia di università nel mondo. È autore di molti autorevoli libri sulla tecnologia database; i più recenti: SQL and Relational Theory: How to Write Accurate SQL Code  (2009) – O’Reilly; Database Explorations: Essays on The Third Manifesto and Related Topics (co-autore con Hugh Darwen, 2010)

L'articolo Il futuro del modello relazionale proviene da Data Manager Online.