Newsgroup: it.comp.reti.locali
Titolo: Ma che si fuma il garante della privacy?

Dubito che ci mettano del tabacco...
in riferimento a:
Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati 
con strumenti elettronici relativamente alle attribuzioni delle funzioni 
di amministratore di sistema - 27 novembre 2008
(G.U. n. 300 del 24 dicembre 2008)
vedere 
http://www.garanteprivacy.it/garante/doc.jsp?ID=1577499
in parole povere, ora bisogna centralizzare il log server (e questo ï¿œ il 
meno..)
vedendo le faq si nota:
11) Come va interpretata la caratteristica di completezza del log? Si 
intende che ci devono essere tutte le righe? L'adeguatezza rispetto allo 
scopo della verifica deve prevedere un'analisi dei rischi?
La caratteristica di completezza ï¿œ riferita all'insieme degli eventi 
censiti nel sistema di log, che deve comprendere tutti gli eventi di 
accesso interattivo che interessino gli amministratori di sistema su 
tutti i sistemi di elaborazione con cui vengono trattati, anche 
indirettamente, dati personali. L'analisi dei rischi aiuta a valutare 
l'adeguatezza delle misure di sicurezza in genere, e anche delle misure 
tecniche per garantire attendibilitï¿œ ai log qui richiesti.
e di seguito
15) Cosa dobbiamo intendere per evento che deve essere registrato nel 
log? Solo l'accesso o anche le attivitï¿œ eseguite?
Il provvedimento non chiede in alcun modo che vengano registrati dati 
sull'attivitï¿œ interattiva (comandi impartiti, transazioni effettuate) 
degli amministratori di sistema. Si veda la risposta alla faq n. 11.
Quindi a che cazzo serve?
Vogliono un log server centralizzato che teoricamente dovrebbe essere 
inaccessibile all'amministratore di sistema, e allora chi lo amministra 
il suddetto log-server?
Vogliono un backup su supporto non riscrivibile e possibilmente 
certificato..
Ma senza avere la lista dei comandi impartiti..
Quindi se faccio un dump del DB e scp verso nuovi orizzonti.. tutto OK?
Mi sa tanto di maga cazzata all'italiana, si vorrebbero tutelare i dati 
personali/sensibili dall'amministratore di sistema ma l'unico effetto 
sarï¿œ come sempre di aggiungere complessitï¿œ e costi inutili per aziende e PA.
PS: ma Winbug puï¿œ salvare i log su sislog?


unicamnete a loggare gli ACCESSI dell'amministratore al sistema .
Poi cosa abbia fatto esattamente in quell'accesso , lo dovr� spiegare al 
magistrato ,se c'� stata una fuga di dati a lui denunciata . 

AlessandroA ha scritto:

Si come no, si da una bella ritoccatina ai log e voil� tutto sparito.
Poi si masterizza, ci si mette il timestamp e tutto quello che vuoi.

 magistrato ,se c'ï¿œ stata una fuga di dati a lui denunciata . 
Appunto, come dimostri chi ha fatto cosa se parti dal presupposto che 
sia stato l'AdS a trafugare i dati.
Ovvio che l'AdS ha e avrï¿œ sempre e comunque accesso ai suddetti, ma ce 
l'ha pure l'omino incaricato di cambiare la cassetta ogni mattina (nella 
PA sono rimasti all'era del nastro), ce l'ha pure l'installatore 
dell'applicazione che generalmente ï¿œ un dipendente di una ditta che 
copre un area geografica regionale per conto della software house 
principale, il programmatore che realizza il software, tutti quelli che 
lavorano presso l'ufficio in questione, chi detiene le chiavi della 
cassaforte o piï¿œ probabilmente del cassetto in cui vengono custoditi i 
nastri ecc...
In pratica i dati sensibili per esempio i dati anagrafici dei comuni 
sono quasi di pubblico acceso tanto piï¿œ che l'installatore del software 
non sï¿œ nemmeno che Oracle dovrebbe avere una password..

Andrea B. ha scritto:

A che pro? visto che loggi solo gli accesi, non puoi sapere se ho fatto 
un dump del DB e trasferito sulla mia chiavetta USB o spedito via scp su 
altro server o se semplicemente ho copiato i dati direttamente dal 
backup senza nemmeno loggarmi sul server.

Diavolinux ha scritto:

Certo, infatti volevo sottolineare che anche la pretesa inalterabilit�
dei log � priva di senso.

 PA sono rimasti all'era del nastro), ce l'ha pure l'installatore 
perch� tu i backup dove li fai?
-- 
MirkoB.   
ne...@bsi-net.it
Motoretta BMW R1150R Nera...
L'indirizzo em@il non � da considerarsi pubblico,
ma utilizzabile solo per temi inerenti il NG corrente.

>>>>  
http://www.bb2002.it
 :)  <<<<<
........... [ al lavoro ] ...........

 sono quasi di pubblico acceso 
nanetto:
chiedo al comune la lista nome-cognome-indirizzo dei nati nel 196x del mio 
comune
"non si pu�, � la privacy"
allora chiedo di consultare gli elenchi/registri elettorali, me li smazzo 
per due ore e li restituisco; all'impiegata faccio notare:
"adesso so tutto di tutti: nome-cognome-indirizzo-statocivile-
titolodistudio-luogoedatadinascita-razziemazzi: che razza di privacy 
sarebbe questa?" :P
per� ho sprecato due ore del mio tempo quando con una query mi poteva dare 
il POCO che mi serviva in 20 secondi :(


 dischi rimovibili (p.e. IoMega) *E* dischi esterni
e questa sarebbe l'era moderna? io preferisco i miei LTO...


 
mah, vedi, questi signori (i ns clienti) si "confondono" spesso e per 
velocizzare le operazioni di ripristino la strada pi� veloce � quella di 
fargli riprendere  il file "che non c'� pi�" con un semplice drag&drop ;)


 fargli riprendere  il file "che non c'� pi�" con un semplice drag&drop ;)
che per un utente finale di una piccola realt� sia pi� facile posso
concordare, ma definire "l'era dei nastri" come preistoria direi che �
un pochetto azzardato. Infondo se hanno sviluppato nastri da 1.6TB con
prestazioni che fanno impallidire i vari dischi rimovibili/esterni
direi che proprio preistoria non �, anzi!


 
concordo


 Poi si masterizza, ci si mette il timestamp e tutto quello che vuoi.
Il problema è che c'è sempre qualcuno al di sopra del bene e del male:
root
Per attenuare i rischi si:
1) archiviano i dati in uno storage che non consente la cancellazione
dei dati. Tu sarai root sul log server, e sullo storage sarai in
grado di scrivere ma non sarai in grado di cancellare. Mo' non scendo
nei particolari di questa tecnologia. Un esempio per tutti (che non è
alla portata economica di tutti): EMC Centera
2) attivare un audit completo anche sul log server. In questo modo se
zappi qualcosa, comparirà tra gli audit del log server, e se fermi
l'audit sul log server sarà ravvisabile un vuoto nell'auditing.
3) la stessa persona che è root sul log server non dovrebbe essere root
sulle macchine target. Questo migliora le cose solo un pochettino.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 dei log è priva di senso.
http://italy.emc.com/products/family/emc-centera-family.htm



Facebook: Massimo Bacilieri

 
piccolissima premessa: credo che quella norma potrebbe essere stata
stabilita a livello europeo. I prodotto a cui faccio riferimento sono
progettati per questo scopo, e essendo americani, non sono proprio
ad-hoc per le nostre normative.
Tornando all'argomento:
Nelle situazioni più comuni, cioè nella stragrande maggioranza dei casi,
hai ragione tu, ma _volendo_ con un po' separazione dei ruoli e balle
varie qualcosa si riesce ad ottenere. 
Stavo dicendo che innanzitutto deve esserci un audit attitvo anche sul
log server (audit, non logging).
Balle varie:
credo che dovrebbe essere possibile configurare la scrittura degli
audit (quantomeno quelli del log server) per mandare i dati in tempo
reale sullo storage in oggetto.
Se fai in questo modo il comando "kill -9 <id_audit>" andrà
immediatamente sullo storage e non potrai più cancellarlo. 
Poi (almeno in teoria) dovrai dar conto di quel comando di 'kill' e
dell'audit fermo per quel tot. tempo in qui avrai ipoteticamente
vandalizzato gli audit dei server.
Però, ripeto, nella norma è assolutamente come dici tu: puoi fare il
cacchio che vuoi, anche perché in pratica per attuare un sistema di
questo tipo che sia veramente funzionante devi mettere in moto processi
che rischiano di essere inapplicabili e ingestibili.
non la prendere come pubblicità (anche perché non me ne può fregare di
meno), comunque dai un'occhiata a questo prodotto:
http://www.sensage.com
 (è un prodotto relativamente complesso che - per
la cronaca - gira su linux).


 
Non so dove hai vissuto negli ultimi 4/5 anni...
Comunque nel 2006 gi� venivano pubblicati documenti tipo:
http://italy.emc.com/collateral/hardware/white-papers/h2312-backup-disk-planning-options.pdf
Guarda caso praticamente tutte le grandi aziende offrono sistemi di 
backup remoto e nessuno fa uso di nastri.
Ma quando � stata l'ultima volta che hai aggiornato il DRP?
Da qualche parte dovresti aver definito l'RTO (Recovery Time Objective) 
che definisce il tempo massimo di down-time delle applicazioni definite 
critiche prima che vi sia un grave impatto economico per l'azienda 
(applicazioni definite dall RPO Recovery Point Objective)
Ora, se uno ha fatto i compiti come richiesto ha testato il tutto 
mettendo down il server con il simpatico lettore di nastri..
E non ci vuole un genio per capire che se non ho il lettore di nastri 
connesso ad un server funzionante ripristinare il tutto in tempi decenti 
� praticamente impossibile quindi che me ne faccio dei nastri?
Scelta + logica � avere una macchina virtuale sul server A ed una copia 
sul server B in stand by che funge da NAS di backup sia che siano 
immagini di VM sia che siano tar.gz o .zip
Nell'istane in cui dovr� ripristinare un backup dovr� soltanto estrarlo 
dal tar.gz e sincronizzare le 2 macchine, in caso di danno hardware mi 
baster� far partire la VM sul server di backup e quindi ho tutto il 
tempo per ordinare un nuovo server master, caricare l'SO, installare il 
gestore di VM che preferisco (attualmente WMware) e ripristinare lo 
status iniziale, il tutto facendo perdere all'azienda meno di 5 minuti 
(se si dovesse sfasciare il server).

 
Un disco removibile esterno o un nas sono senza dubbio piï¿œ pratici di un 
nastro ma fondamentalmente presentano gli stessi limiti, in caso di down 
  hardware di un server serve a poco avere "solo" il backup dei files o 
il dump del DB, serve anche ripristinare l'operativitï¿œ del server stesso 
con tutti gli applicativi installati e configurati o sobbarcarsi un tot 
di giorni di down il chï¿œ oggigiorno ï¿œ impensabile anche per l'azienda 
piï¿œ piccola.
I dischi removibili ed i piccoli nas andrebbero utilizzati solo per 
espandere la capacitï¿œ di storage del server, compito che svolgono 
egragiamente, ma in ogni caso un server di backup pronto a sostituire il 
master si rivela la scelta migliore.

 
Perch� ci saranno sempre in circolazione clienti come te che ne fanno 
richiesta, quindi per un effetto di domanda/offerta continueranno a 
supportarli finch� sar� economicamente vantaggioso.
Anche i dischi SCSI sono obsoleti rispetto ai SAS, ci� non significa che 
i produttori smetteranno di produrli, finch� ci sar� un mercato 
continueranno a farne ma la tecnologia va avanti in ogni settore 
indipendentemente dalle scelte del singolo responsabile IT.
Il nastro pu� essere pure considerato un ottimo supporto ma negli ultimi 
anni sono subentrate tecnologie e problematiche totalmente diverse 
rispetto a 5/10 anni fa che rendono il backup su nastro qualcosa di 
preistorico per le suddette ragioni.

 qualcosa di preistorico per le suddette ragioni.
Questa è una tua convinzione.  Nessun altro supporto garantisce una 
sicurezza ed una durata paragonabile ai nastri.
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

 Giovanni
Ma svegliati CAZZO! siamo nel 2009! pure in Microsoft se ne sono resi conto!
http://blogs.sysadmin.it/ermannog/archive/2008/10/13/3115.aspx
In pratica ti stanno dicendo.. prendi i tuoi nastri ed infilateli nel culo!
Penso sia sufficentemente chiaro..

 
http://blogs.sysadmin.it/ermannog/archive/2008/10/13/3115.aspx
Ma ROTFL... si � vero quel backup non supporta i nastri, ma solo
perch� vogliono che tu spenda un po' di pi� per prendere la versione
completa che guarda caso li supporta.
Non vorrei dire ma quel sistema di backup � la parte pi� criticata di
2008, e meno male che fare l'upgrade alla versione completa costa
poco.


 Penso sia sufficentemente chiaro..
Se il progresso è come la tua educazione benvenuta la preistoria :-)


 preistorico per le suddette ragioni.
spiegale. E poi spiegami dove trovi un supporto da 1.6TB che costa
40eur che te lo puoi mettere in tasca, portarlo a casa e archiviarlo
senza problemi (e non parliamo delle prestazioni).


 status iniziale, il tutto facendo perdere all'azienda meno di 5 minuti 
tutto ci� potrebbe avere un senso per ridurre il fermo macchina, ma
non ha nulla a che vedere con il backup.


 non ha nulla a che vedere con il backup.
Come sopra, sei rimasto agli anni '90..
Come cazzo fai a backuppare un ORACLE RAC (Real Application Cluster) che 
ti gira su 4 o pi� server in parallelo.. con la cassetta?
Ma non diciamo cazzate! Le banche che fanno i backup su nastro, ma per 
favore.. nemmeno in Ruanda!
Le transazioni finanziarie devono avvenire a livello atomimico, mai 
sentito parlare di triggers, stored procedure ecc..
Forse sarebbe ora che qualche responsabile IT cominci a metter mano al 
Business Continuity Planning della propria organizzazione prima di 
venire a sparare cagate sulle banche..
Un buon documento da cui iniziare per esempio potrebbe essere:
http://www.swissbanking.org/it/11107_i.pdf
Ti immagini se una filiale di una banca fa BOOM!
Aspetta, dove abbiamo messo i backup? Ce li aveva il Direttore nella sua 
cassaforte a casa peccato che sia morto nell'esplosione.. Ora che 
raccontiamo ai correntisti?
Mettetevi comodi, arriveranno i pompieri a scassinare la cassafore del 
f� Direttore, sperando che con la fiamma ossidrica non danneggino i 
nastri con i dadi dei vostri CC..
Ma dai, siamo seri..

 nastri con i dadi dei vostri CC..
ROTFL


>>>>  
http://www.bb2002.it
 :)  <<<<<

Mandi! Diavolinux
  In chel dì si favelave...
D> PS: ma Winbug può salvare i log su sislog?
...può essere istruito a farlo:
 
http://ntsyslog.sourceforge.net/
-- 
   Di questa cavolo di pianura, di questa gente senza misura, che gia`
   confonde la notte e il giorno, e la partenza con il ritorno, e la
   richezza con i rumore, ed il diritto con il favore	(F. De Gregori)