View Comments (17)

• Per me la cosa non ha senso. Nel caso dei vari cms/crm/etc, l'accesso al database non e' effettuato da parte dell'utente finale, ma da parte del framework del sito, quindi e' un processo interno del sistema.
  Altrimenti, con la stessa logica, bisognerebbe loggare:
  - Gli accessi al pam/ldap/qualsiasi altro backend di autenticazione usato dal server ftp
  - Gli accessi ai diversi db usati dai vari moduli di spamassassin (bayes, stats)
  - Gli accessi al db da vpopmail
  - Gli accessi all'authdaemon di courier
  - etc.
  E poi come la mettiamo con gli utenti windows server che si collegano ad un db access attraverso odbc? O quelli di linux che si collegano a pervasive via iodbc?

  Quindi, a parte le difficolta tecniche, sospetterei che il log di accesso al dbms serve solo quando l'utente finale lavora direttamente sul database (che non e' un caso raro, se usciamo dal contesto web).

• Ad ogni modo, se si dovesse implementare il log degli accessi su mysql, non sarebbe niente di difficile.
  Basta attivarlo come spiegato nell'articolo, fare un piccolo script che estragga solo le righe rilevanti, lasciando stare le query, e schedularlo. Ovviamente si possono anche zippare per la questione spazio. Il tutto in 10 min di lavoro da parte di un tecnico competente.

• @Bubi: con questa norma quando l'amministratore di sistema/dba si collega ad un database deve essere registrato su un "access log" il suo collegamento e il relativo quit. Non deve essere loggato il collegamento "applicativo" (punto 22 delle faq). Inoltre la soluzione proposta da te (lo script) non ti permette d'avere quelle caratteristiche di "completezza, inalterabilità e possibilità di verifica della loro integrità" perchè vai ad alterare o ad estrarre una parte dei log originati dal dbms.

• @MyBSide, i p.10, 11, 12 del faq ti contraddicono. Riporto qui la parte piu' importante:
  Comunque è sempre possibile effettuare un'estrazione o un filtraggio dei logfiles al fine di selezionare i soli dati pertinenti agli AdS.

• @Bubi: mmm quindi tu dici sostanzialmente di abilitare il logging, poi fare un rotatelog, usare uno script con grep | awk | sed | ecc... girare tutto su un altro file, firmarlo digitalmente e siamo a posto ?

  Però... mmm non va in contrasto con il punto 16 ?

  
  La raccolta dei log serve per verificare anomalie nella frequenza degli accessi e nelle loro modalità (orari, durata, sistemi cui si è fatto accesso…). L'analisi dei log può essere compresa tra i criteri di valutazione dell'operato degli amministratori di sistema.

  Se io amministratore faccio uno script che mi estrae dei dati da un log... volendo posso anche non metterci dentro un accesso che non voglio venga loggato, no ?
  Forse non ho capito io o forse si è espresso male il garante ma per me i concetti di inalterabilità e integrità vanno in contrasto con un'estrapolazione (fatta con uno script o a mano)...

  Infine il punto nr. 10 lo *interpreto* come: in caso di richiesta da parte dell'autorità, io devo fornire i dati d'accesso al database, nel caso in cui il file di quel giorno sia troppo grande allora posso fornire solo un estratto ma il log di per sè non deve subire alterazioni e deve essere sempre possibile verificarne l'integrità.

  Cmq grazie per il tuo punto di vista, fammi sapere che ne penso del mio ;)

• Ops... doveva essere un "fammi sapere che ne pensi del mio" ;)

• @MyBSide, naturalmente non posso avere la certezza che il mio punto di vista sia quello giusto, e lo stesso vale per il tuo. E cmq, vista l'assurdità del provvedimento stesso, non mi stupisce il fatto che vi siano delle parti interpretabili in diversi modi.
  Quindi parlando di contrasti, personalmente considero l'intera iniziativa come un contrasto con la realtà; l'amministratore di sistema, sopratutto se è unico, potrà sempre manomettere il log di qualsiasi cosa. Mi chiedo come mai sia nata l'idea, magari il garante o chi per lui, avrà visto un sistemista aggirarsi per i corridoi indossando la famosa maglietta "i read your mail" :-)

  Tornando alla parte tecnica, io non vedo altre soluzioni tranne il filtraggio dal file. MySQL non supporta i trigger sui SELECT, e non esiste la possibilità di loggare solo le connessioni. Dalla versione 5.1.qualcosa, dovrebbero aver implementato la possibilità di scrivere i log in una tabella e non su file, cosa che faciliterebbe il filtraggio ma aumenterebbe l'overhead. Ovviamente si potrebbe modificare il sorgente (in caso di installazioni compilate direttamente sulla macchina), ma ciò renderebbe difficile/richiederebbe più tempo per aggiornare in futuro il software.
  Oppure si potrebbe utilizzare un trucco, implementare il log al livello application logic. Tipo il root potrebbe connettersi non direttamente con un client, ma con un wrapper che scriva un log e faccia poi partire il client. Ma questo potrebbe andare in contrasto con qualche punto del provvedimento.

  Io penso che ignorerò tutta questa assurdità. Ho appena dato un occhiata alle statistiche di uno dei server più carichi (hosting web), sono ~250 query al secondo. Quindi si tratta di più di 20 mln al giorno e più di mezzo miliardo al mese. Aldilà del filtraggio successivo, trovo criminale loggare tutto questo, anche se la macchina (multiprocessore/multicore/raid) reggerebbe.
  E poi, di norma uso phpmyadmin per fare qualsiasi cosa su mysql, quindi in questo caso andrebbe loggato (lo fa già apache) il mio accesso al phpmyadmin, perché la parte phpmyadmin->mysqld potrebbe essere classificabile come un "collegamento applicativo" :-)

• @Bubi: beh sull'assurdità siamo d'accordo credo :) Il problema è che tanti faranno così. Tanti... almeno quelli che trattano dati sensibili + mysql. Io al posto d'usare phpmyadmin userò cmq "l'applicazione mysql" (virgolettata stile laserone di Austin Powers) e quindi rientrerò pure io nel “collegamento applicativo” ;)

  Il vero casino però è che tu fai hosting web e se uno dei tuoi clienti vorrà trattare dati sensibili con il tuo mysql...

  Mboh facci sapere nel caso :(
  Grazie cmq per la risposta ! Ehehe

• Ah per la cronaca... è stato rilasciato ieri

  Zen Cart 1.3.8 Remote SQL Execution Exploit

  Pensate che bello quando uno lavora, viene loggato il suo accesso e "certificato" mentre da fuori accedono al db e magari fanno delle frodi...

  In questo caso un colpevole certo esiste...

• @MyBSide, normalmente nei contratti firmati dai clienti, ci sono diverse clausole liberatorie sui dati gestiti, che servono per parare le chiappe al hoster, quindi la situazione è meno incasinata di quanto potrebbe sembrare :-)

  Per quanto riguarda il caso dei software open bucati, ci sono due casi: se lo installa il hoster, e non lo aggiorna in tempo/non limita i danni, la colpa e' appunto del hoster, ed e' giusto che sia cosi'. Se invece e' il cliente ad installarsi qualcosa e viene hackato, sono anche cavoli suoi :-) .

  Se vogliamo continuare a fare altri esempi di quanto sia assurda la questione circa il salvataggio degli access log, ecco un altro: Io ho la workstation in ufficio sempre accesa e con le sessioni ssh, verso i server in datacenter, sempre attive. Fino a qualche raro reboot. Quindi il /var/log/secure sui server, con una decina di connect all'anno, e' sicuramente molto utile per l'audit...