none
Risalire a chi ha effettuato in un DB una cancellazione di viste non prevista RRS feed

  • Domanda

  • Ciao.

    Su un DB MSSQLServer 2008 R2 sono state "droppate" due viste.
    Ho provveduto a restorarle ma dopo un po di analisi mi sono accorto di un paio di utenti sul db con diritti di owner (gli unici in grado di fare questa operazione). Il mio obiettivo sarebbe di riuscire a scoprire "chi ha cancellato cosa" . Ho trovato un po' di documentazione in giro ma sembra che questa operazione sia possibile farla unicamente un DB con Recovery Model a FULL e il mio DB è a SIMPLE.  Avrei due domande:

    1) Non c'è traccia di operazioni di cancellazione oggetti nel log di SQL di "default" ? 

    2) Cosa devo attivare per poterlo "scoprire" in futuro ? Forse una trace "leggera" che monitori e registri ogni operazione di questo tipo ? non c'è altra soluzione piu "standard" e magari "nativa" ? 

    Grazie a tutti in anticipo.


    Hunternet

    lunedì 27 giugno 2016 14:02

Risposte

  • Ciao

    Sfortunatamente, il log di SQL Server (del servizio) non va a loggare le operazioni che fai custom sul tuo database, ma solo quelle cose che sono relative, appunto al servizio, come cambiamenti di path, impostazioni e quant'altro.

    Credo che le operazioni di quel tipo, soprattutto in ambienti di produzione NON DEBBANO ESSERE FATTE. In produzione, una drop è, a mio avviso, se non opportunamente discussa, un suicidio e owner con così tanto controllo, non dovrebbero nemmeno esistere. Questo sempre secondo la mia visione della security ed, in generale, dei processi.

    In aggiunta, un change ha una request, e viene fatto solo dopo che questa è approvata, oltretutto in ambienti di sviluppo e solo successivamente in test per la prova. 

    Detto questo, ti consiglio di aggiungere le DENY sul DROP degli oggetti, almeno per il futuro sei pronto. Più in generale, le modifiche in produzione, eccetto nel caso di indici (che comunque non dovrebbero essere creati ondemand subito, ma schedulati e valutati) e poco altro, dovrebbero essere negate, o confermate previo processo di richiesta.

    Purtroppo quello che hai provato sulla tua pelle accade quando la security è, temo, è considerata un'opzione. Se non vedi dal change history report, se non hai abilitato qualche software che ti monitorizza i drift (come ad esempio DLM Dashboard di Red Gate) purtroppo temo tu non abbia soluzioni.

    Mi spiace essere critico su questa cosa, ma la sicurezza è una cosa per cui c'è da investire veramente tanto tempo, proprio per non trovarsi nella spiacevole (me ne rendo conto) situazione a cui stai assistendo. E non sempre si può fare qualcosa a posteriori.


    Alessandro Alpi - Data Platfomr MVP - CTO & Co-Founder Engage IT Services S.r.l.

    martedì 28 giugno 2016 10:48
    Moderatore

Tutte le risposte

  • Ciao,

    hai provato a lanciare il report "Schema Changes History"?

    Il report puoi trovarlo in Management Studio, a livello di server -> Tasto destro -> Reports -> Standard Reports -> “Schema Changes History”, e si alimenta con i dati della default trace (se abilitata), che si resetta ad ogni restart del servizio di SQL.

    Se ti interessa avere maggiore profondità storica, forse potresti considerare l'utilizzo di DDL Triggers.

    lunedì 27 giugno 2016 21:29
  • Ciao

    Sfortunatamente, il log di SQL Server (del servizio) non va a loggare le operazioni che fai custom sul tuo database, ma solo quelle cose che sono relative, appunto al servizio, come cambiamenti di path, impostazioni e quant'altro.

    Credo che le operazioni di quel tipo, soprattutto in ambienti di produzione NON DEBBANO ESSERE FATTE. In produzione, una drop è, a mio avviso, se non opportunamente discussa, un suicidio e owner con così tanto controllo, non dovrebbero nemmeno esistere. Questo sempre secondo la mia visione della security ed, in generale, dei processi.

    In aggiunta, un change ha una request, e viene fatto solo dopo che questa è approvata, oltretutto in ambienti di sviluppo e solo successivamente in test per la prova. 

    Detto questo, ti consiglio di aggiungere le DENY sul DROP degli oggetti, almeno per il futuro sei pronto. Più in generale, le modifiche in produzione, eccetto nel caso di indici (che comunque non dovrebbero essere creati ondemand subito, ma schedulati e valutati) e poco altro, dovrebbero essere negate, o confermate previo processo di richiesta.

    Purtroppo quello che hai provato sulla tua pelle accade quando la security è, temo, è considerata un'opzione. Se non vedi dal change history report, se non hai abilitato qualche software che ti monitorizza i drift (come ad esempio DLM Dashboard di Red Gate) purtroppo temo tu non abbia soluzioni.

    Mi spiace essere critico su questa cosa, ma la sicurezza è una cosa per cui c'è da investire veramente tanto tempo, proprio per non trovarsi nella spiacevole (me ne rendo conto) situazione a cui stai assistendo. E non sempre si può fare qualcosa a posteriori.


    Alessandro Alpi - Data Platfomr MVP - CTO & Co-Founder Engage IT Services S.r.l.

    martedì 28 giugno 2016 10:48
    Moderatore
  • Ti ringrazio . Sei stato molto gentile ed esplicativo nella risposta ... riguardo la "buona norma" di comportamento condivido ogni tua parola e infatti certi stati di configurazione cerco di lasciarli "isolati" e in istanze "dedicate" alle applicazioni come queste che , purtroppo, richiedono dei requisiti per poter girare che vanificano ogni tentativo di sicurezza . Credo che l'unica salvezza sarebbe effettuare preventivamente un rigoroso filtro riguardo la "software selection" da parte di chi sceglie scegli i prodotti da installare! Ciao e grazie ancora.


    Hunternet

    venerdì 1 luglio 2016 13:55