Corporate IT Policy & #Netiquette

Reintrodurre un po’ il concetto di Netiquette potrebbe aiutare a risolvere quel problema di autismo che i vari dipartimenti IT (e società) stanno continuando a creare, rendendo difficile la comunicazione tra Aziende, e quindi anche il Busi

Diverse volte al GeekTalks si è parlato di quanto sia difficile reperire informazioni sulle modalità di gestione dei sistemi informative di Aziende con cui collaboriamo. In svariate occasioni è possibile trovare difficoltà nel contattare lo staff IT di un’Azienda, un NOC se si parla di strutture complesse, o più di frequente, il Postmaster, la figura cioè che si occupa delle problematiche di comunicazione elettronica con l’Azienda.

Il caso è principalmente organizzativo, non certo tecnico. Il problema più comune che si può incontrare è quello di essere impossibilitati ad inviare messaggi e-mail ad un determinato interlocutore, con messaggi di errore vari, dall’impossibilità di recapitare il messaggio per SPAM oppure perché il messaggio è stato “permanentemente rifiutato” per motivi non meglio dichiarati. Il risultato è la segnalazione di “guasto ai servizi di posta elettronica” e un’analisi euristica del problema da parte dello staff IT del mittente.

La prima cosa che verrebbe da pensare – tecnicamente – è quella di verificare i dati del Dominio di posta in questione. Purtroppo spesso e volentieri capita che i dati siano estremamente generici. L’admin-c di un dominio è decisamente una persona non tecnica, il Technical Contact è comunemente il registrar stesso e i dati non sempre sono dischiusi. Per non parlare dei netblock, che ancor peggio sono malgestiti in linea generale. Sui siti Internet dell’azienda, infine, i dati sono di poca utilità, in quanto non è mai menzionato l’indirizzo E-Mail del supporto IT o di chi contattare in caso di difficoltà. Men che meno, non sono menzionate le modalità di gestione dei servizi, quali la posta elettronica.

La soluzione, come per svariati altri problemi in ambienti in cui le implementazioni seguono delle Linee Guida standard, è di carattere sociale. Abbiamo, infatti, spostato l’attenzione dal problema tecnico in se, per un problema di comunicazione: il lato mittente, infatti, non sa generalmente come contattare il supporto della controparte per poter analizzare e risolvere il problema. Per questa ragione abbiamo iniziato ad abbozzare una sezione da rendere pubblica sul sito Corporate dell’azienda, una sorta di Disclaimer sulla gestione dei sistemi informativi dell’Azienda.

L’obiettivo è quello di mettere  a disposizione di un Cliente o un Fornitore le informazioni tecniche minime necessarie per poter collaborare e scambiare efficientemente informazioni attraverso il canale telematico Internet. Generalmente inseribile all’interno di una sezione come “Policy” o sotto una voce “Sistemi Informativi” delle informazioni sull’Azienda (il “Chi siamo” per intenderci) la pagina potrebbe contenere informazioni preziose come:

• Come contattare il supporto tecnico (telefono, e-mail)
• Policy di gestione dei servizi di posta elettronica (es. filtri anti-spam, dimensione massima degli allegati, tipi di file non consentiti)
• Informazioni sulle contromisure di sicurezza
• Dettagli tecnici sulle applicazioni web erogate (se presenti)
• Informazioni sulle limitazioni dei servizi di scambio dati (es. FTP server)

Partendo dal presupposto che le Aziende necessitino di poter lavorare e gli strumenti elencati sono solo alcuni esempi, mettere a disposizione le informazioni essenziali è un modo per consentire ai dipartimenti IT di poter da un lato accedere ad informazioni cruciali della propria controparte, dall’altro di sapere come accedere al supporto tecnico per qualsiasi necessità in caso di problemi.

Supponiamo un esempio pratico, più che mai all’ordine del giorno. Un vostro utente invia un allegato in DWG ad un Cliente. Il destinatario respinge il messaggio con un messaggio di cortesia. L’utente della vostra struttura, inevitabilmente, vi inoltrerà l’email con l’errore.
In condizioni “normali” (ossia: sempre) vi troverete a dover fare congetture o contattare l’Azienda per avere delucidazioni. Se poi, come spesso capita, il servizio è in Cloud o l’IT è esterno alla struttura, i tempi si allargano.

In condizioni in cui la “Netiquette” sia applicata, avreste una pagina su cui andare (magari citata nel messaggio di errore) in cui trovereste che:

• determinati tipi di allegati non sono consentiti;
• dimensione massima dell’allegato;
• politiche restrittive verso indirizzi e-mail di un certo dominio;
• regole di verifica e controllo dei record DNS;
• come contattare il supporto tecnico per eventuali problemi.

Questo metodo, evolvibile e sicuramente più dettagliabile, porterebbe ad una maggiore collaborazione tra strutture, permettendo un intervento più efficace ed indubbiamente per migliorare la produttività delle varie strutture.

Con il crescente diffondersi di Firewall di tipo applicativo (Layer-7) inoltre, sapere con chi andiamo ad interloquire (e soprattutto come) diventa molto più controllato. Questo significa che se il nostro “visitatore” (sia esso Cliente o Fornitore) ha una difesa perimetrale come quella indicata, in determinate condizioni, potrebbe avere difficoltà (o impossibilità) a raggiungere i servizi che esponiamo. Prendendo come esempio il Apple-Store e Watchguard XTM come esempio, le policy di base di questo apparato impediscono all’utenza di poter fare acquisti o aggiornamenti sul Apple Store dagli applicativi perché rimuove tutte le intestazioni “X-Apple*” dalla comunicazione HTTP. Il “Disclosure” di questo tipo di parametri, soprattutto per società che operano con una grande vastità di interlocutori, farebbe risparmiare un boato di tempo ai dipartimenti IT e, molto più importante, alle Aziende.

Con il gruppo GeekTalks stiamo lavorando a dei template di esempio di informazioni da pubblicare, sulla base delle esperienze personali e di reali esigenze sviluppate nel corso di anni, che renderemo disponibili appena pronte.