[PRIVACY] Misure entro il 15/12/09
Messjah
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.
Yena
-----------------------------------------------------
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 --
Gandalf Corvotempesta
> Ve lo immaginate masterizzare i log di un mail-server serio che tiene i
> 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.
Davide Bianchi
io dico che non superarai 1 dvd ogni 6 mesi.
Io faccio 20Gb alla settimana...
Davide
Yena
> Yena ha scritto:
>> Ve lo immaginate masterizzare i log di un mail-server serio che tiene
>> i log x 6 mesi ..
>
> Se comprimi in bzip2 con -9 io dico che non superarai 1 dvd ogni 6 mesi.
>
Ottimista :-)
-- Yena --
Argaar
ma tu sei in olanda....o anche li ci sono c******i con la penna in mano
dentro ministeri che scribacchiano
Mao
> Ciao a tutti,
> 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.
>
>
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
Gandalf Corvotempesta
> io sto risolvendo cosￜ:
> 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
Gandalf Corvotempesta
> io sto risolvendo cosￜ:
> 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.....
Argaar
> Messjah ha scritto:
>> Ciao a tutti,
> [CUT]
>> 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.
>>
>>
>
> io sto risolvendo cosￜ:
> http://blog.maurizio.proietti.name/2009/10/26/provvedimento-del-garante-sugli-amministratori-di-sistema/
>
> Saluti
> M.
>
>
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?
Gandalf Corvotempesta
> 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.
Argaar
> Argaar ha scritto:
>> o sto solo sbagliando l'interpretazione?
>
> Io credo che se devi registrare i log degli amministratori,
>
> 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...
Andrea B.
Forse qualcuno violer� la legge.
Gandalf Corvotempesta
> 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?
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.....
Mao
>> io sto risolvendo cosￜ:
>> http://blog.maurizio.proietti.name/2009/10/26/provvedimento-del-garante-sugli-amministratori-di-sistema/
>>
> 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?
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 :-) )
Mao
> Mao ha scritto:
>> io sto risolvendo cosￜ:
>> 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.....
>
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
:-)
Gandalf Corvotempesta
> 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)
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...
Mao
> Se hai 300-400 database sul server il logging
> senza il pipe ￜ un suicidio, imho.
in effetti...
>
> 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...
Ottima idea, non avevo pensato alle named pipe.
Posso aggiungere al tua soluzione nel post sul blog?
(citandoti se mi passi un link)
Gandalf Corvotempesta
> in effetti...
Te lo confermo, con la soluzione identica a quella
del blog (sei te l'autore per caso?) mi si ￜ
atterrata la macchina in pochi secondi.
> 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 :)
Mao
> Te lo confermo, con la soluzione identica a quella
> del blog (sei te l'autore per caso?) mi si ￜ
> atterrata la macchina in pochi secondi.
>
Si, sono l'autore dell'articolo :-)
Grazie, non avevo modo di testarla su un ambiente
con tanti db :-(
>
> vai vai...
> se mi scrivi, ti dico cosa citare, la mail ￜ buona :)
fatto
Giuseppe Della Bianca
Si, anche perchè se usa il bzip2 non bastano sei mesi per fare
l'archivio .....
P.S. :P
Gandalf Corvotempesta
> Gandalf Corvotempesta ha scritto:
>>
>
> 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)
usenet
> Il 11/11/2009 15:03, Argaar ha scritto:
>> 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?
>
> Una volta che li hai salvati su cd non sono pi� modificabili.
??? Li modifico e cambio il CD! l'inalterabilit� del supporto non ha
nulla a che vedere con l'inalterabilit� dei dati in esso contenuti.
> 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.....
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..
Andrea B.
> 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 �...
Mettere nel cron il calcolo dell'hash e spedirselo con la PEC?
Gandalf Corvotempesta
> ??? Li modifico e cambio il CD! l'inalterabilit� del supporto non ha
> 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)
Gandalf Corvotempesta
> 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.
usenet
Esatto!
Andrea B.
Certo io sono il sysadm e quindi sono dio, � per questo che sono
perplesso. Molto perplesso.