Newsgroup: it.comp.os.linux.sys
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.

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

 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).


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)