Devo DENY UPDATE esplicitamente alle colonne che non devono essere aggiornate?

Sono abituato a lavorare in ambienti molto sicuri e quindi progetto i miei permessi con un livello di granularità molto fine. Una cosa che faccio normalmente è esplicitamenteDENY agli utenti la possibilità di UPDATEcolonne che non dovrebbero mai essere aggiornate.

Per esempio:

create table dbo.something (
    created_by varchar(50) not null,
    created_on datetimeoffset not null
);

Queste due colonne non devono mai essere modificate una volta impostato il valore. Pertanto vorrei esplicitamente DENYilUPDATE permesso su di loro.

Di recente, durante una riunione del team uno sviluppatore ha sollevato il punto secondo cui la logica per garantire che i campi non vengano mai aggiornati dovrebbe essere contenuta nel livello dell'applicazione e non nel livello del database nel caso in cui "debbano aggiornare i valori per qualche motivo". Per me sembra la tipica mentalità degli sviluppatori (lo so, ero uno!)

Sono l'architetto senior della mia azienda e ho sempre lavorato sul principio del minor numero di privilegi necessari per far funzionare l'app. Tutte le autorizzazioni sono controllate regolarmente.

Qual è la migliore pratica in questo scenario?

L'argomento non ha senso. Voglio sempre i controlli e i vincoli il più vicino possibile ai dati. Inserirlo nel livello applicazione significa che influisce solo sulle persone che utilizzano il livello applicazione e presuppone inoltre che il codice sia privo di bug e che la sicurezza attorno a tali percorsi di codice sia a prova di proiettile. Questi sono grandi presupposti.

Se devono assolutamente essere aggiornati, ciò può essere fatto da una persona non interessata dall'esplicito DENY, oppure la persona può essere temporaneamente spostata in un ruolo che non è interessato o DENYpuò essere temporaneamente rimossa. Queste sono cose che sono facili per te, come DBA, per impostare il controllo in giro. Nell'app? Non così tanto.

Concordo pienamente con @Aaron sull'aspetto tecnico di questo.

Oltre a ciò direi, per quanto riguarda le migliori pratiche:

1. Dato che è compito / responsabilità del DBA proteggere i dati, l'approccio di default dovrebbe essere quello di fare proprio questo, come ritiene opportuno il DBA, e richiedere un solido business case per fare un cambiamento. Un ipotetico-futuro-potenziale-un po 'possibile-dato-certe-condizioni-che-saranno-brainstormed-dopo-e-confermato-ben-dopo-quello-ma-forse-cambiato-dopo-o-potrebbe-mai - una ragione che si verifichi (ad esempio "per qualche motivo") sembra un po 'esile da una giustificazione, specialmente quando l'argomento sta cambiando uno standard / una pratica aziendale.

2. Non fidarti mai di qualcuno che vuole apportare modifiche a qualcosa che non dovrebbe mai cambiare ;-), (ancora di più se non sanno nemmeno perché lo vogliono).

3. Dì allo sviluppatore che sono invitati ad aggiungere tale logica al codice dell'app per impedire tali aggiornamenti. Ma anche che non rimuoverai DENY. Se / quando verrà mai il giorno (e cosìpotrebbe non farloprobabilmente non lo farà) che qualcuno riceve un errore nel tentativo di aggiornare una di queste colonne, quindi puoi discutere se rimuoverai o meno DENY, il che richiederà una giustificazione effettiva e solida sul perché qualcuno dovrebbe aggiornare quel valore nel primo posto.

   Il punto è che dovrebbe esserci un vero caso aziendale alla base di ciò che le persone trascorrono il loro tempo. Il tempo è molto richiesto ma l'offerta è scarsa, quindi tu (e tutti gli altri) avete cose più importanti da fare che cambiare il sistema in base all'opinione di qualcuno. Ci sarà sempre una varietà di opinioni (spazi vs tab, chiunque?) E potresti passare anni a cambiare questo avanti e indietro se lo sviluppatore lascia e viene sostituito da uno che si oppone fortemente a quei campi che sono aggiornabili. Se nessun cliente lo richiede (o qualcosa che lo richiede) e non vi è alcun beneficio tangibile (anche benefici ritardati come la pulizia del debito tecnico, che è difficile mostrare il ROI, ma è molto utile, dato che il le probabilità che il tempo trascorso non comporti un effettivo risparmio sui costi nel lungo periodo sono scarse a nessuno), quindi chiudere la richiesta o inserirla nel backlog con una priorità bassa, anche nei casi in cui l'idealismo dice che dovrebbe essere cambiata (questo non è uno di quei casi, ma menzionato per quelli che pensano che sia). L'idealismo è ottimo per le conversazioni, ma le aziende non possono pagare l'affitto, le utenze, i dipendenti, le tasse, ecc. Con ideali.

4. @ jpmc26 ha ragione sulla necessità di comunicare, ma non esattamente su ciò che deve essere comunicato. Sì, dovresti ascoltare ciò che gli altri stanno chiedendo e cercare di capire il loro ragionamento, che include porre domande se non sei chiaro su qualcosa.

   TUTTAVIA, il database non è subordinato all'applicazione e i professionisti del database (amministratori, ingegneri, qualunque sia il nome utilizzato dall'azienda) non sono subordinati agli sviluppatori (come sembra implicito nella risposta). Non lavori per gli sviluppatori, lavori per l'azienda, proprio come loro. Questo è uno sforzo di squadra e non dovresti chiedere perdono per aver fatto il tuo lavoro. Detto questo, noi tipi di computer non siamo (generalmente) conosciuti per le nostre capacità comunicative interumane, quindi, devi davvero assicurarti che gli altri ti capiscano , qual è il tuo ragionamento, quali sono le tue responsabilità E come funzionano queste cose .

   Ho inserito l'ultima parte perché c'è un alto grado di incomprensioni, disinformazione e mancanza di conoscenza là fuori (anche alcuni proprio qui in questa stessa pagina). Ad esempio, sembra esserci questa idea che tutte le regole sono regole aziendali. Dobbiamo spiegare che esiste una distinzione tra regole dei dati e regole aziendali (@Aaron si riferiva a questo come "vincolo del flusso di lavoro vs vincolo dei dati" in un commento sulla domanda) e che mentre la maggior parte dei dati appartiene naturalmente all'applicazione, alcuni dati appartiene effettivamente al modello di dati. Un DBA dovrebbe dettare agli sviluppatori come saranno vincolati i dati dell'applicazione ? Ovviamente no. È nostro compito offrire come i dati dell'applicazione possono iessere vincolato. Se una violazione di una regola aziendale correlata ai dati dell'applicazione potrebbe causare danni e l'app non è l' unico modo al 100% di manipolare i dati, forse un vincolo di controllo potrebbe davvero aiutare (e non è difficile modificarli o rimuoverli ).

   MA, provenienti dall'altra direzione, gli sviluppatori non dovrebbero dettare come vengono gestiti i dati del modello di dati (cioè i metadati). Ciò include i campi di controllo (come le colonne created_on/ created_by) e le colonne PK / FK (questi valori dovrebbero essere conosciuti solo internamente e non dati ai clienti). Questi dati non sono ciò che l'app memorizza sui clienti (anche se l'app può vedere i valori e persino usarli, come con gli ID), è ciò che il modello di dati memorizza sui dati dell'app.

   Quindi ha senso utilizzare le regole dei dati per proteggere i dati del modello di dati. E farlo non implica che stai per iniziare ad aggiungere vincoli o restrizioni ai dati dell'applicazione. MA sarà difficile portare avanti la conversazione in modo veramente produttivo se questa distinzione non viene compresa.

Così:

1. Sì, mi piace l'idea dell'esplicito DENYnelle colonne di controllo e ho proposto lo stesso anche in posti in cui ho lavorato in passato.

2. Aneddoticamente, ho avuto una conversazione molto simile con uno sviluppatore principale (molto valido), forse nel 2000, quando ho iniziato ad aggiungere chiavi esterne. Ha sostenuto (abbastanza seriamente) che non era necessario un eccessivo ingegnerismo / idealismo (qualcosa del genere, sono passati 17 anni da quella conversazione) e non valeva il colpo di prestazione. Era abbastanza chiaro che la pulizia dei dati correlati dovrebbe essere gestita nel livello dell'app. (sì, ho aggiunto gli FK perché non sarebbe stato lui a ripulire i dati orfani che il suo codice avrebbe inevitabilmente creato)

   Anni dopo si scusò per aver discusso quell'argomento ;-)

Questo è probabilmente un problema XY. Lo sviluppatore probabilmente non è particolarmente interessato a bloccare gli aggiornamenti in un campo veramente costante come created_on. Questo esempio particolare è un vincolo estremamente modesto.

Lo sviluppatore è probabilmente preoccupato che il team DBA (che include te) intenda aggiungere così tante o così complesse restrizioni che inizi a ostacolare la loro capacità di lavorare in modo efficace, o che quando si presenta qualcosa fuori dall'ordinario o qualcosa cambia, il team DBA resisterà ai cambiamenti e ostacolerà la capacità del team di sviluppatori di fare progressi. Questa è una preoccupazione relativamente ragionevole. Burocrazie e perdita della capacità di effettuare i cambiamenti necessari sono eventi reali e la codifica di vincoli troppi o complessi può avere effetti negativi sulle prestazioni e sulla capacità di rispondere ai cambiamenti nei requisiti.

Lo sviluppatore potrebbe anche non rendersi conto che questa è la natura delle loro preoccupazioni. Probabilmente sono abituati ad avere il regno libero del database e rinunciare a quel livello di libertà è difficile, specialmente se sai di non averlo mai abusato. Quindi il loro senso di preoccupazione per la perdita della capacità di fare ciò di cui hanno bisogno potrebbe essere vago e mal definito.

Quindi ci sono un paio di cose che dovresti fare per alleviare queste paure:

1. Comunicare intensamente con gli sviluppatori. Assicurati di comprendere le esigenze delle funzionalità che stanno cercando di creare e di essere pronto a rispondere quando arrivano le modifiche. Ascolta ciò che hanno da dire e lavora sodo per trovare una soluzione che bilanci le loro preoccupazioni con le tue. Sii disposto a piegarti quando hanno bisogni legittimi. Assicurati che sappiano che sei un alleato nella creazione del software.
2. Sii cauto nel porre restrizioni. Le restrizioni, anche quelle intese a fornire integrità e sicurezza, possono rendere più difficile adattarsi al cambiamento o affrontare circostanze impreviste. Quindi comprendi che ogni restrizione aggiunta ha la stessa probabilità di avere un costo associato ad essa così come è probabile che risparmi i costi (con la possibile eccezione delle chiavi primarie ed esterne, che praticamente non hanno aspetti negativi). Assicurati che le restrizioni che imponi siano realmente necessarie o utili.
3. Non vedo alcun segno che tu stia facendo questo, ma voglio menzionarlo per tutti gli altri lettori: non visualizzare i dati o il database come responsabilità tua o del tuo team. I dati sono una risorsa per l'intera azienda. Senza un sistema per archiviarlo (il database) e script, strumenti o applicazioni per crearlo, aggiornarlo e recuperarlo, i dati sono inutili. Poiché tutti devono utilizzare questa risorsa, i dati sono responsabilità di tutti. Il database stesso è solo una parte per ottenere valore dai dati.

Hai dichiarazioni contrastanti

• Colonne che non dovrebbero mai essere aggiornate
• Hanno bisogno di aggiornare i valori per qualche motivo

Sta davvero a te dettare il primo?

Concedi il minimo privilegio per far funzionare l'app senza prove che l'app non avrà mai bisogno di aggiornare il valore.

Chi è responsabile dell'integrità dei dati?

Con i vincoli SQL puoi garantire l'integrità dei dati? No, non è possibile in quanto vi sono spesso regole aziendali che vanno oltre ciò che un database può fare.

VendorID non dovrebbe mai cambiare, ma cosa succede se due fornitori si fondono. Mai dire mai.

Se il team dell'app contamina i dati e afferma di aver bisogno di tale autorità, dipende da questi. Se i team di app funzionano per te, puoi dettare.

La domanda appropriata è se l'app aggiorna mai i dati.