Come posso evitare il jack accidentale con un database di produzione?

31

Proprio di recente, uno sviluppatore ha tentato accidentalmente di ripristinare un database in produzione, quando avrebbe dovuto ripristinare una copia temporanea. È facile da fare, dato che i nomi db sono simili, ad esempio CustomerName_Staging contro CustomerName_Production.

Idealmente, li avrei su scatole completamente separate, ma ciò è proibitivo in termini di costi e, a rigor di termini, non impedisce che accada la stessa cosa se l'utente si collega alla scatola sbagliata.

Questo non è un problema di sicurezza, di per sé - è stato l'utente corretto a lavorare con il database di gestione temporanea e se c'è del lavoro da fare sul database di produzione, lo sarebbe anche lui. Mi piacerebbe avere un ufficiale di spiegamento per separare quelle preoccupazioni, ma il team non è abbastanza grande per quello.

Mi piacerebbe ricevere alcuni consigli in termini di pratica, configurazione e controlli su come evitarlo.

sql-server best-practices

— Chris B. Behrens
fonte

25

Gli sviluppatori non dovrebbero avere accesso in scrittura ai database di produzione o, preferibilmente, alcun accesso.

— Michael Hampton

12

@MichaelHampton - Siamo io e lui. Sono anche uno sviluppatore. Che cosa suggerisci?

— Chris B. Behrens,

10

Separare gli account utente per ciascun ruolo (dev vs ops / DBA). E un'abbondanza di cautela.

— Michael Hampton

2

Consiglio vivamente di avere il proprio ambiente di produzione in una scatola separata. Altrimenti la stadiazione e la produzione devono condividere risorse - disco, CPU, ecc. - e se la stadiazione monopolizza una risorsa che può subire il vostro ambiente di produzione.

— Thorbjørn Ravn Andersen,

1

Basta avere utente / password separati per quei database.

— neutrinus,

32

Se questo è qualcosa che ti vedi fare spesso, automatizzalo. E poiché entrambi siete sviluppatori, scrivere del codice dovrebbe essere nella vostra timoniera. :) Seriamente però ... automatizzandolo, puoi fare cose come:

Verifica che stai ripristinando sul server corretto (es. Nessuno sviluppatore -> ripristini prodotti)
Verifica che sia il "tipo" giusto di database (nel tuo caso, "stadiazione" e "produzione")
Scopri quali backup ripristinare automaticamente guardando le tabelle di backup in msdb

Eccetera. Sei limitato solo dalla tua immaginazione.

— Ben Thul
fonte

1

È un'idea interessante ... abbiamo già un codice che gestisce i ripristini db (per i test automatizzati). Potremmo mettere uno strato di astrazione tra quello che ha sempre indicato la messa in scena in modo che il ripristino alla produzione fosse un processo completamente diverso ...

— Chris B. Behrens,

11

Ora stai pensando con i portali. :)

— Ben Gio,

4

Per i lavori automatizzati che incidono sulla produzione, mi piace aggiungere un passaggio manuale che richieda all'utente di digitare la parola "produzione" per ridurre la possibilità di pensare che stiano guardando, ad esempio, l'equivalente di messa in scena.

— Joe Lee-Moyet,

2

Ho effettuato il downgrade perché nessuno dovrebbe avere accesso alla produzione per impostazione predefinita. Devi avere un processo speciale per recuperare una password prod. È scomodo ma davvero il minimo.

— OliverS,

1

@BenThul L'aggiunta di un altro account per l'accesso ai prod e il fatto di renderlo un ulteriore inconveniente è ancora la soluzione giusta per me. La necessità aziendale non è far risparmiare 2 minuti al DEV ma ripristinare il DB che può essere spostato perfettamente in un account prod.

— OliverS,

32

Non sono d'accordo con il presupposto della domanda - questa è sicurezza - ma non sono nemmeno d'accordo sul fatto che l'automazione salverà la giornata da sola. Inizierò con il problema:

Non dovresti essere in grado di fare accidentalmente nulla alla produzione!

Ciò include fare cose automatizzate per errore.

Stai confondendo la sicurezza del sistema con concetti come "a chi è permesso fare cosa". I tuoi account di sviluppo dovrebbero poter scrivere solo sulle loro copie, sul server di controllo della versione e sul database degli sviluppatori. Se riescono a leggere / scrivere la produzione, possono essere hackerati e sfruttati per rubare i dati dei clienti o (come hai dimostrato) possono essere maltrattati nel perdere i dati dei clienti.

È necessario iniziare ordinando il flusso di lavoro.

I tuoi account sviluppatore dovrebbero essere in grado di scrivere sulle proprie copie, sul controllo della versione e magari passare dal controllo della versione in un ambiente di test.
Gli utenti di backup dovrebbero solo poter leggere dalla produzione e scrivere nel proprio archivio di backup (che dovrebbe essere adeguatamente protetto).
Fare qualsiasi altra lettura / scrittura sulla produzione dovrebbe richiedere un'autenticazione speciale e scomoda . Non dovresti riuscire a scivolarti dentro o dimenticare di aver effettuato l'accesso. Il controllo dell'accesso fisico è utile qui. Smart card, flip-switch per "armare" l'account, accesso simultaneo a doppia chiave.

L'accesso alla produzione non dovrebbe essere qualcosa che devi fare ogni giorno. La maggior parte del lavoro dovrebbe riguardare la piattaforma di test e le implementazioni fuori orario effettuate in produzione dopo un attento controllo. Un piccolo inconveniente non ti ucciderà.

L'automazione fa parte della soluzione.

Non sono cieco al fatto che il pieno inversione di tendenza (caricamento su VCS, controllo della copertura, pull su server di prova, esecuzione di test automatizzati, riautenticazione, creazione di un backup, pull da VCS) è un processo lungo.

Ecco dove l'automazione può aiutare, secondo la risposta di Ben. Esistono molti linguaggi di scripting diversi che rendono l'esecuzione di determinate attività molto, molto più semplice. Assicurati solo di non rendere troppo facile fare cose stupide. I tuoi passaggi di riautenticazione dovrebbero comunque essere pronunciati (e se pericolosi) dovrebbero essere scomodi e difficili da fare senza pensare.

Ma da solo l' automazione è peggio che inutile. Ti aiuterà solo a fare errori più grandi con meno pensieri.

Adatto a squadre di tutte le dimensioni.

Ho notato che hai indicato la dimensione della tua squadra. Sono un ragazzo e me lo sono fatto perché ci vuole solo una persona per avere un incidente. C'è un sovraccarico ma ne vale la pena. Si finisce con un ambiente di sviluppo e produzione molto più sicuro e molto più sicuro.

— oli
fonte

2

Inoltre, una cosa che mi piace fare è utilizzare due account nominati per utente. Uno è per il normale accesso dell'utente, il funzionamento, il lavoro quotidiano, ecc., Mentre il secondo account (di solito con una sorta di suffisso come un + o un carattere di sottolineatura) ha tutti i diritti di produzione e sviluppo richiesti dall'utente. In questo modo, l'utente deve prendere una decisione attiva per spingere a produrre invece di dev. Questo è simile al punto 3 sopra descritto, ma non richiede una significativa infrastruttura o spesa aggiuntiva per dimostrare il valore.

— user24313

3

È anche importante evitare di prendere l'abitudine di fare qualsiasi cosa tranne la manutenzione del tuo account. A tal fine, assicurati che prod non riesca a vedere il codice sorgente, non possa avviare un IDE, ecc.

— Eric Lloyd,

Dove trovo uno di quegli aggeggi a doppia chiave a giro simultaneo e viene fornito con USB?

— Lilienthal,

Qualcos'altro che potrebbe aiutare è automatizzare completamente (uno o due clic) le procedure di gestione temporanea e sviluppo, ma non automatizzare completamente le distribuzioni di produzione. Dover remotare manualmente nella scatola per fare qualsiasi cosa per la produzione ma non per altri ambienti è una differenza significativa in termini di praticità, come suggerisci. (Potresti comunque scrivere tutti i passaggi necessari e utilizzare quello script in tutti gli ambienti; ciò che intendo è che dovresti licenziare manualmente l'esecuzione di detti script per la produzione.) Questo ovviamente può essere fatto in aggiunta al tipo di autenticazione procedure che consigliate.

— jpmc26

1

@Lilienthal Era una metafora del teatro ad alta sicurezza ma si poteva emulare l'attacco economico di chiavette USB a ciascuno sviluppatore e quindi far controllare l'automazione di almeno due dei loro numeri di serie quando si eseguono cose pericolose. In team più grandi è quindi possibile accedere per vedere chi interferisce con la produzione e ritenere responsabili le persone giuste quando tutto va storto.

— Oli,

12

Uno dei miei colleghi ha un approccio interessante a questo. La sua combinazione di colori terminali per la produzione è fugace . Grigio e rosa e difficile da leggere, che teoricamente dovrebbe garantire che qualunque cosa scriva, intendeva davvero scrivere.

Il tuo chilometraggio può variare ... e probabilmente non devo dire che è a prova di proiettile da solo. :)

— robhol
fonte

2

Uso anche un grande colore di sfondo rosso sui terminali / connessioni db ai server di produzione, nonché sfondi rosso vivo per gli account di amministrazione sui PC ...

— Falco

Sì, lo stavo pensando. Rendi rosso l'autopompa di produzione ...

— Chris B. Behrens,

La codifica a colori aiuta. Proprio come in un IDE.

— Thorbjørn Ravn Andersen,

1

Gli sviluppatori non dovrebbero conoscere la password del database di produzione. La password del prod dovrebbe essere casuale e non memorabile - qualcosa come il risultato di tastiera mashing ( Z^kC83N*(#$Hx). La password può essere dev $YourDog'sNameo correct horse battery stapleo qualsiasi altra cosa.

Certo, potresti scoprire qual è la password, specialmente se sei un piccolo team, guardando il file di configurazione dell'applicazione client. Questo è l'unico posto dove dovrebbe esistere la password prod. Ciò garantisce che dovresti fare uno sforzo deliberato per ottenere la password del prod.

(Come sempre, è necessario disporre di backup temporizzati per il database di produzione. Ad esempio, con MySQL, archiviare i registri binari come backup incrementali. Per PostgreSQL, archiviare i registri write-ahead. Questa è la protezione dell'ultima risorsa per qualsiasi tipo di disastro, autoinflitto o altro.)

— 200_success
fonte

Non posso essere pienamente d'accordo con questo, perché in qualsiasi grande ambiente realistico ci sono casi abbastanza regolari in cui gli sviluppatori / amministratori devono accedere al database di produzione. Certo in un mondo perfetto con un sistema impeccabile questo non dovrebbe mai accadere, ma nella maggior parte dei sistemi so che devi correggere manualmente alcuni dati critici di produzione ... Quindi sono con Oli, il login di produzione dovrebbe essere scomodo, ma fattibile

— Falco

1

@Falco Questo è esattamente quello che sto suggerendo però. Inconveniente ma fattibile.

— 200_successo

Il problema con il tuo approccio è solo, se c'è un'emergenza e la produzione è in calo, il tempo conta. Quindi i tuoi sviluppatori dovrebbero sapere dove trovare la password e ottenerla velocemente. Se devono chiedere in giro, cerca nel repository e configura i file e prova a perdere tempo prezioso = denaro. Quindi preferirei avere la password in un posto dove tutti sanno dove cercare, ma è comunque scomodo, ma veloce se necessario

— Falco

2

@Falco Poiché gli ambienti prod dovrebbero rispecchiare da vicino gli ambienti dev, il file di configurazione dovrebbe trovarsi in una posizione analoga sul server prod come sulle macchine dev. Qualsiasi sviluppatore competente dovrebbe sapere dove cercare e se non sanno dove cercare, allora vuoi quel ritardo, proprio per prevenire danni del tipo indicato nella domanda.

— 200_successo

Non conoscere le password non ostacola gli incidenti. Al contrario, crea motivazione per cercare la password solo una volta, dopodiché lo sviluppatore può iniziare a utilizzare la cronologia bash o persino creare un alias per connettersi al database. E poi, è più probabile che si verifichino incidenti.

— k0pernikus,

0

La risposta breve è RBAC - controllo degli accessi in base al ruolo.

Le tue autorizzazioni per tutti gli ambienti devono essere diverse e fastidiose come cose come UAC, ne hai bisogno: specialmente per gli ambienti PROD.

Non c'è MAI motivo per gli sviluppatori di avere accesso diretto a Prod, indipendentemente da quanto piccola sia l'organizzazione / il team. Il tuo "Dev" può anche indossare i cappelli "Stage" e "Prod", ma deve avere credenziali e processi diversi per colpire ambienti diversi.

È fastidioso? Assolutamente. Ma [aiuta] a prevenire il borking dei tuoi ambienti? Assolutamente.

— conigliera
fonte

0

Una soluzione semplice e veloce: utilizzare due account utente diversi, uno per il normale lavoro di sviluppo che ha solo accesso al database di sviluppo e uno diverso per operare effettivamente sul database di produzione, con pieno accesso ad esso. In questo modo, dovrai cambiare attivamente l'account che stai utilizzando prima di poter apportare qualsiasi cambiamento nella produzione, il che dovrebbe essere sufficiente per prevenire errori accidentali.

Lo stesso approccio può essere utilizzato se si hanno due siti Web, o due server o due interi ambienti: un account utente per lo sviluppo senza accesso (o almeno nessun accesso in scrittura ) alla produzione, un altro account utente per lavorare sul sistema di produzione ( S).

Questo è lo stesso approccio di un amministratore di sistema con un account non amministratore standard per il lavoro di routine (lettura di e-mail, navigazione Web, tracciamento dei biglietti, archiviazione di schede, scrittura di documentazione, ecc.) E un account distinto per amministratore completo da utilizzare durante il funzionamento effettivo su server e / o Active Directory.

— Massimo
fonte