Come si limita l'accesso all'ambiente di produzione nell'azienda per cui si lavora?

Nella società per cui lavoro, gli ingegneri di Devops (attualmente solo 2 membri, che sono io e un altro collega) sono le uniche persone che hanno accesso al database di produzione.

Quindi, quando qualsiasi altro sviluppatore deve eseguire una query MySQL sul database di produzione. Avrebbero inviato la query ai 2 ingegneri per consentire loro di eseguirla.

Ecco le situazioni in cui è necessario eseguire comandi nel database di produzione:

1. Il database contiene dati danneggiati, che producono bug. Eseguono comandi per correggere i bug.

2. È stato segnalato un bug. E vogliono vedere i valori correnti all'interno del database.

3. Uno dei nostri clienti desidera modificare i propri dati. Ma la nostra applicazione web non ha la possibilità di effettuare la modifica. Quindi dobbiamo inviare i comandi MySQL direttamente al database per completare i requisiti del cliente.

4. Il team addetto al controllo qualità ha creato account di prova nell'ambiente di produzione. E vogliono cambiare lo stato dell'account in modo da poter fare altri test.

Questo crea molte interruzioni per me l'altro collega. Quando sviluppiamo programmi durante il giorno, spesso dobbiamo cambiare contesto solo per eseguire alcune query.

Non penso che questa sia una buona architettura per l'azienda. Come controlli le autorizzazioni per l'ambiente di produzione nella tua azienda?

Il nostro database di produzione è costituito da informazioni sensibili dei clienti. Se i dati venissero divulgati, la nostra azienda potrebbe essere multata per milioni di dollari.

Se la tua domanda è come gestire le modifiche al database, considera qualcosa come Flyway . Ciò ti consente di controllare le modifiche tramite i file di configurazione monitorati nel tuo repository e di applicarle tramite un processo automatizzato e controllato: utilizza i normali passaggi di revisione e promozione del codice.

Se la domanda è "come faccio a impedire agli sviluppatori di smettere di darmi fastidio per eseguire comandi SQL arbitrari", allora potresti prendere in considerazione l'idea di creare uno script per automatizzarlo o fornire loro un'interfaccia utente di terze parti da utilizzare con un account bloccato per impedire li modifica e impedisce loro di vedere le tabelle sensibili. YMMV a seconda del layout del tuo DB.

È possibile incorporare lo schema del database e le modifiche dei dati nel controllo del codice sorgente utilizzando un concetto chiamato migrazioni del database. Questi possono quindi essere eseguiti su ambienti di sviluppo e di gestione temporanea come parte di un processo di distribuzione parzialmente automatizzato.

Ad esempio nel mio ambiente (applicazione Web PHP), sto usando Doctrine Schema per gli aggiornamenti dello schema, le migrazioni Yii2 per le modifiche dei dati. I rispettivi comandi fanno parte di uno script bash a 7 righe che esegue tutti i comandi necessari per distribuire una modifica in ciascun ambiente

Vedo un primo problema, DevOps riguarda la creazione di team in grado di gestire un'applicazione dalla compilazione allo sfruttamento.
Quindi i tuoi sviluppatori dovrebbero avere accesso ai database, hai citato vari casi che sono la realtà per molte persone e il principale svantaggio che sta trasformando te e il tuo collega in un collo di bottiglia e impedendo il proprio lavoro.

Altre risposte affrontano bene la modifica dello schema o la modifica pianificata che dovrebbe effettivamente essere integrata come parte del processo di consegna dell'applicazione, ma non consentono di risolvere rapidamente la necessità di accesso in tempo reale, quando uno sviluppatore potrebbe dover scaricare il DB per capire cosa ha causato il bug e come risolverlo per esempio.

Cose come ProxySQL che hai già citato in un commento potrebbero andare bene per i database MySQL, anche solo configurare MySQL per registrare le cose potrebbe essere un buon approccio, MySQL offre un plug-in di controllo commerciale che potrebbe rispondere al problema di consentire ai tuoi sviluppatori di accedere al database e soddisfare il tuo Requisiti del CISO per tenere traccia di ciò che viene fatto.

Se hai più di un semplice database Mysql e devi controllare il loro accesso, configurare ciascun sistema per controllare le azioni degli utenti del registro e non le azioni dell'applicazione potrebbe essere complicato. Mantenere le cose chiuse potrebbe essere anche peggio, un giorno un giorno integrerà una shell DB in un'applicazione per aggirare questo blocco stradale e alla fine entrerà in produzione senza un adeguato controllo degli accessi ed esporrà tutti i dati, ti consiglio vivamente di chiedere al tuo società per rivedere questa politica.

C'è una soluzione commerciale che conosco che può aiutare (e consentire il controllo più delle semplici richieste DB) che è strongDM , che consente anche di controllare le sessioni ssh e rdp, come se i tuoi sviluppatori necessitassero dell'accesso al DB, probabilmente hanno anche bisogno dell'accesso al macchine che ospitano le applicazioni per scopi di debug.

... io e un altro collega ... siamo le uniche persone che hanno accesso al database di produzione.

Questa è una buona posizione di partenza.
Troppo spesso i DBA si ritrovano a cercare di chiudere la porta della stalla dopo che il cavallo è fuggito.

Quindi, quando altri sviluppatori devono eseguire una query MySQL sul database di produzione ...

Domanda:
Perché gli sviluppatori eseguono qualcosa contro il database di produzione?

Come controlli le autorizzazioni per l'ambiente di produzione nella tua azienda?

Controllo degli accessi in base al ruolo.

Gli utenti hanno accesso a ciascun database man mano che lo richiedono il proprio ruolo lavorativo e vengono utilizzati i ruoli per consentire loro di accedere alle tabelle all'interno di ciascun database. Il processo attraverso il quale vengono creati questi account e i ruoli assegnati sono gestiti centralmente e rigorosamente controllati.

Gli sviluppatori non dovrebbero mai avere "pratici", aggiornare l'accesso al di fuori dei loro database di sviluppo. Tutto il resto dovrebbe essere scritto, testato, verificato e rilasciato attraverso canali pre-preparati, controllati (e, preferibilmente, automatizzati).