Fino a qualche anno fa, la mia carriera si era svolta come dipendente all'interno di dipartimenti IT.
Ogniqualvolta mi si presentasse la richiesta, da parte del dipartimento Internal Audit o del responsabile della sicurezza, di un monitoraggio delle mie attività e di quelle dei miei colleghi, storcevo il naso: "Ma non se ne parla neanche!", "Abbiamo ben altro da fare, dobbiamo far andare avanti il business!", "Abbiamo bisogno di un elevato grado di libertà e di superare determinate barriere" e poi, in ultimo ma con definitiva determinazione "Ma dal punto di vista della Privacy, hai verificato che si possa fare?"
All'accenno della Privacy dei dipendenti e dei potenziali ostacoli posti dalla normativa italiana sul lavoro e dalle rappresentanze sindacali, il progetto di controlli si arenava silenziosamente e inesorabilmente.
Accade talvolta però che la propria inossidabile resistenza al cambiamento venga intaccata da una serie di eventi che la rendono più duttile e malleabile alle istanze esterne.
Sto parlando di quelle situazioni di difficoltà in cui è necessario dare delle risposte a fronte di interruzioni di un servizio all'utenza, quelle situazioni in cui viene puntato il dito verso un presunto probabile responsabile.
Per ogni servizio esiste un gruppo variegato di stakeholder, costituito dagli utenti del servizio, che possono essere interni o esterni nel caso di servizio in outsourcing, dai responsabili dell'erogazione del servizio e, non ultimi, dagli amministratori di sistema.
Nel caso di outsourcing le cose si complicano sensibilmente, perché all'erogazione di un servizio corrispondono dei livelli di servizio garantiti che hanno delle conseguenze anche economiche.
Ebbene, in che situazione si può trovare l'amministratore a fronte di avvenimenti interruttivi provocati sia da problemi di sistema sia da errore umano?
In qualcosa di questo genere:
- nel non poter dimostrare di non avere effettuato un'operazione che aveva condotto a un'interruzione di servizio;
- nell'incapacità di determinare chi, dei vari sistemisti di un gruppo di supporto, avesse svolto una determinata attività che aveva portato a un'interruzione di servizio;
- ad accumulare ritardi indotti dal tentativo di ripristino di una situazione precedente alle modifiche introdotte alla configurazione (chi caspita si ricordava cosa era stato fatto durante la configurazione e com'era esattamente la situazione prima della modifica?)
Pensate poi a episodi di fughe di informazioni dall'interno. Chi viene messo sotto osservazione per primo? Di certo il dipartimento IT, che è quello che, secondo l'opinione comune, detiene la maggior parte delle conoscenze su sistemi. Sappiamo che questo non sempre è vero per quanto riguarda i dati, che sono spesso dominio di conoscenza di altre funzioni aziendali.
Perché quindi sopportare questo aggravio di responsabilità?
Per garantire la privacy del lavoratore?
Ma un lavoratore, secondo il buon senso, la deontologia e non ultimo il codice civile italiano, non dovrebbe
"..usare la diligenza richiesta dalla natura della prestazione dovuta, dall’interesse dell’impresa e da quello superiore dell’interesse nazionale; deve inoltre osservare le disposizioni per l’esecuzione e per la disciplina del lavoro impartitegli dal datore di lavoro o dai collaboratori di questi da cui il lavoratore dipenda gerarchicamente."(art. 2104 c.c.) ?E quindi dove si pone il problema nel monitorare soltanto le attività sui processi più critici? Attenzione, io non sto proponendo di monitorare le attività del singolo lavoratore, ma di monitorare ciò che viene effettuato negli ambiti più critici dell'azienda, laddove il livello di attenzione sulla sicurezza deve essere più elevato, pena il detrimento delle attività dell'azienda stessa (e quindi anche di chi lavora per essa).
Quando aumenta la complessità nelle infrastrutture IT, gli amministratori implementano soluzioni che permettono di monitorare e mantenere efficacemente questi ambienti.
Ma spesso la domanda "Chi è stato l'ultimo ad accedere a quel server e cosa ha fatto?" rimane senza risposta.
Non è abbastanza monitorare server e applicazioni quando la causa numero 1 dei downtime è l'errore umano: parlate con un esperto di alta affidabilità e il discorso toccherà presto questo argomento.
In più, il problema di mantenere l'uptime è esacerbato dalla dipendenza crescente dall'outsourcing, da consulenti esterni, da impiegati temporanei e sviluppatori che amministrano server e software, una situazione che porta a una diminuzione della responsabilità diretta.
Per raggiungere un'operatività efficiente, gli amministratori devono avere una visione olistica dell'infrastruttura IT, ivi incluso il monitoraggio del fattore umano.
Ben vengano, quindi, policy, procedure e strumenti che consentono di monitorare le attività negli ambienti critici, che tengano quindi traccia di chi ha fatto che cosa e dove, tenendo ben presente però che:
1) il responsabile del controllo non deve essere una funzione dell'IT;
2) di concerto, gli strumenti non possono venire gestiti in toto dal dipartimento IT (che avrebbe quindi la piena padronanza di essi);
3) deve essere monitorata la loro disponibilità e devono essere istanziati immediati avvisi in caso di non disponibilità dello strumento (per evitare che vengano spenti o sconnessi premeditatamente).
Come funzionario IT mi sentirei più garantito se potessi dimostrare la limpidezza del mio operato e se fosse possibile individuare anche gli errori umani in modo più rapido e preciso.
Chi non vuole permettere tutto ciò, o ha qualcosa da nascondere o non si sente completamente sicuro delle proprie competenze e capacità.
