Newsgroup: it.comp.os.linux.sys
Titolo: [PRIVACY] Misure entro il 15/12/09

Ciao a tutti,
sperando di non essere OT, e visto che mi hanno appioppato l'ennesima rogna 
da risolvere, volevo solo chiedere come vi state comportando su server LiNUX 
per ottemperare alla nuova follia sistemistica richiesta dal Garante Privacy 
(
http://www.garanteprivacy.it/garante/doc.jsp?ID=1577499
).
Avete usato solo script? Sinceramente la direttiva non mi sembra 
chiarissima...e viste le sanzioni previste non vorrei fare qualche 
castroneria.
Grazie a tutti,
Stefano. 

Messjah ha scritto:

Ci sono le FAQ:
-----------------------------------------------------
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.
Sommario
12) Come va interpretata la caratteristica di inalterabilitï¿œ dei log?
Caratteristiche di mantenimento dell'integritï¿œ dei dati raccolti dai 
sistemi di log sono in genere disponibili nei piï¿œ diffusi sistemi 
operativi, o possono esservi agevolmente integrate con apposito 
software. Il requisito puï¿œ essere ragionevolmente soddisfatto con la 
strumentazione software in dotazione, nei casi piï¿œ semplici, e con 
l'eventuale esportazione periodica dei dati di log su supporti di 
memorizzazione non riscrivibili. In casi piï¿œ complessi i titolari 
potranno ritenere di adottare sistemi piï¿œ sofisticati, quali i log 
server centralizzati e "certificati".
ï¿œ ben noto che il problema dell'attendibilitï¿œ dei dati di audit, in 
genere, riguarda in primo luogo la effettiva generazione degli auditable 
events e, successivamente, la loro corretta registrazione e 
manutenzione. Tuttavia il provvedimento del Garante non affronta questi 
aspetti, prevedendo soltanto, come forma minima di documentazione 
dell'uso di un sistema informativo, la generazione del log degli 
"accessi" (login) e la loro archiviazione per almeno sei mesi in 
condizioni di ragionevole sicurezza e con strumenti adatti, in base al 
contesto in cui avviene il trattamento, senza alcuna pretesa di 
instaurare in modo generalizzato, e solo con le prescrizioni del 
provvedimento, un regime rigoroso di registrazione degli usage data dei 
sistemi informativi.
-----------------------------------------------------
La parte piï¿œ bella ï¿œ quella dell' INALTERABILITA' ......
e al secondo posto:
"..su supporti di memorizzazione non riscrivibili."
Ve lo immaginate masterizzare i log di un mail-server serio che tiene i 
log x 6 mesi ..
-- Yena --
-- Yena --

 log x 6 mesi ..
Se comprimi in bzip2 con -9 io dico che non superarai 1 dvd ogni 6 mesi.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ï¿œ di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

On Nov 9, 6:06 pm, Gandalf Corvotempesta > Se comprimi in bzip2 con -9
io dico che non superarai 1 dvd ogni 6 mesi.
Io faccio 20Gb alla settimana...
Davide

 
Ottimista :-)
-- Yena --

Davide Bianchi ha scritto:

ma tu sei in olanda....o anche li ci sono c******i con la penna in mano 
dentro ministeri che scribacchiano

 
io sto risolvendo cosï¿œ:
http://blog.maurizio.proietti.name/2009/10/26/provvedimento-del-garante-sugli-amministratori-di-sistema/
Saluti
M.
-- 
--
Problemi e soluzioni di un sistemista informatico
http://blog.maurizio.proietti.name

 
http://blog.maurizio.proietti.name/2009/10/26/provvedimento-del-garante-sugli-amministratori-di-sistema/
O yeah!
Per i log di accesso nessun problema, ma per
mysql e windows non sapevo come fare.
Grazie mille

 
http://blog.maurizio.proietti.name/2009/10/26/provvedimento-del-garante-sugli-amministratori-di-sistema/
Il problema ï¿œ che salvare tutto il log di mysql causa un decremento
di prestazioni folle.
Ho attivato il log su pipe con il grep in lettura e fatico ad accedere
al server.....


 
questo perï¿œ a mio avviso non ï¿œ "non modificabile" ossia se io mi 
prendessi un tuo disco su cui ci sono i log, scarico il tar su disco 
fisso, cambio i log eliminando o mettendo alcuni audit eseguiti, 
rigenero gli md5 e rimetto tutto in un cd dopo aver cambiato 
correttamente le date sui file?
o piï¿œ semplicemente, se sono l'amministratore, faccio un dolo e stanotte 
PRIMA che parta il tutto, elimino la riga dove ï¿œ segnato che mi sono 
loggato?
o sto solo sbagliando l'interpretazione?

 o sto solo sbagliando l'interpretazione?
Io credo che se devi registrare i log degli amministratori,
non c'ï¿œ modo di garantirne l'immutabilitï¿œ.
Un amministratore puï¿œ benissimo alterare i dati PRIMA che
vengano inviati ad autority esterne, per cui, credo non ci
sia soluzione. Tanto vale assicurarsi che il log non sia
stato alterato dopo essere stato scritto e non che non sia
alterabile a prescindere.


 
su questo ovviamente sono d'accordo ma a quanto mi ricordo (l'ho seguito 
tempo fa sto discorso) la normativa non prevedeva proprio questo ossia 
dei log di quello che accadeva che una volta generati non fossero 
modificabili da nessuno?
magari ricordo male all'epoca infatti mi chiesi proprio questo...

Argaar ha scritto:

Forse qualcuno violer� la legge.

 modificabili da nessuno?
Una volta che li hai salvati su cd non sono pi� modificabili.
E comunque, non cambia niente, un AdS pu� benissimo alterare
la procedura di esportazione e filtrare determinati accessi.
in tal caso, i log non sarebbero modificabili, ma poco importa,
tanto io te li mando gi� depurati.....

 o sto solo sbagliando l'interpretazione?
Hai ragione, ma dato che i log non hanno alcun
valore probatorio, e non ï¿œ necessaria una
procedura "forte" di non modificabilitï¿œ (da notare
che nelle faq il garante dice espressamente che si
possono filtrare [quindi modificare] i log prima
di salvarli e masterizzarli) la procedura
descritta (IMHO) permette di attuare il
provvedimento senza problemi.
(anche perchï¿œ... se l'amministratore non potesse
modificare i propri log non sarebbe +
amministratore :-) )


 
Anche a me un po' perde in prestazioni, ma il
server gira regolarmente.
Un'altra soluzione potrebbe essere il logging
senza il pipe e a fine giornata filtrare e copiare
tramite rsync o scp sul logserver (che poi a sua
volta provvede alla creazione dell'MD5 e del tar)
Purtroppo non ho trovato altre soluzioni.
Se avete suggerimenti saranno ben accetti
:-)


 volta provvede alla creazione dell'MD5 e del tar)
Se hai 300-400 database sul server il logging
senza il pipe ï¿œ un suicidio, imho.
Io ho fatto una variazione a quanto indicato nel blog.
Non loggo tutto su file ma ho creato una named pipe
ed in inittab ho inserito, in respawn, uno script
cosï¿œ composto:
while [ true ]; do
    tail -f <namedpipe> | egrep 'Connect|Quid' | logger...
done
Le prestazioni sono 'abbastanza' decenti.
Il while sarebbe anche superfluo...

 Il while sarebbe anche superfluo...
Ottima idea, non avevo pensato alle named pipe.
Posso aggiungere al tua soluzione nel post sul blog?
(citandoti se mi passi un link)


 :-)
vai vai...
se mi scrivi, ti dico cosa citare, la mail ï¿œ buona :)

 se mi scrivi, ti dico cosa citare, la mail ï¿œ buona :)
fatto


Yena wrote:

Si, anche perchè se usa il bzip2 non bastano sei mesi per fare
l'archivio .....
P.S. :P

 Ottimista :-)
No, ï¿œ abbastanza verosimile.
Il bzip su file testuali comprime come un maiale.
Non ï¿œ la prima volta che log da 2-3-4gb mi diventano
poche decine di mega, considerato che un dvd tiene
8gb, fai un po i conti....
Magari non sarï¿œ 6 mesi, ma almeno un paio di mesi sicuramente.
(bisogna loggare solo gli accessi, non tutti dettagli come
ogni singola transazione, se ricevi miliardi di mail, non devi
loggare l'intera sessione, ma solo che l'utente X si ï¿œ connesso
in pop3 il giorno Y alle ore Z)

 tanto io te li mando gi� depurati.....
Premesso che il log server esterno dovrebbe teoricamente essere sotto il 
controllo di un altro ADS..
L'unico modo � "certificare" il file come avviene per l'archiviazione 
ottica sostitutiva attraverso una TSA CNIPA.
Ora, dato che apporre una firma digitale e una marca temporale ad un 
file (contenente l'hash del nostro beneamato file di log) non � cosa 
semplicissima dato che (per ora) nessuno sa con esattezza come funziona 
il protocollo delle TSA (visto che implementano anche l'utilizzo di 
username/password per addebitare le marche temporali) la soluzione pi� 
semplice per certificare l'hash �...
Indovinello.. o devo fare tutto io? Spremete le meningi! la soluzione � 
semplicissima ovviamente..

 semplice per certificare l'hash �...
Mettere nel cron il calcolo dell'hash e spedirselo con la PEC?

 nulla a che vedere con l'inalterabilit� dei dati in esso contenuti.
Ma te rompi i coglioni ovunque?
E sai chi � che non si vede da un po, guarda caso da quanto
sei arrivato te? Il caro amico Adamo, che fa i tuoi stessi
identici ragionamenti (sbagliati, tra l'altro)

 Mettere nel cron il calcolo dell'hash e spedirselo con la PEC?
Occhio che Mr. Usenet ti dir� che non va bene, perch� puoi
benissimo alterare i dati prima che il cron li elabori e di
conseguenza genereresti un hash su dati alterati.

Andrea B. ha scritto:

Esatto!

Gandalf Corvotempesta ha scritto:

Certo io sono il sysadm e quindi sono dio, � per questo che sono
perplesso. Molto perplesso.