Il fondatore di business vuole l'accesso al database ma non ha competenze di DB

È il proprietario dei dati . Non tu. Se vieni colpito da un autobus, avrà bisogno di accesso. Dovresti assolutamente dargli accesso. Questa richiesta non è affatto una sorpresa. Se hai creato un sito web per me, chiederei lo stesso.

MA , e questa è la parte importante, non puoi nemmeno competere con lui per l'amministrazione del database. Tu sei l'amministratore, non lui. Ha accesso, ma non può usarlo. Una volta che lo fa, allora sei assolto dalla responsabilità per il database. Questo pezzo di cui hai bisogno per iscritto e deve essere chiaramente compreso. E quindi è necessario accedere al suo accesso.

Sono completamente d'accordo sul fatto che non dovresti combattere per l'accesso root, ma puoi comunque fornire l'accesso al proprietario dei dati senza competere per il controllo.

Sei stato in questa posizione un milione di volte. Spiega solo che potrebbe inavvertitamente rompere qualcosa se non sta attento e gli dà i login come lo possiede lui. Assicurati di fare un db dump prima in modo da poterlo ripristinare se lo interrompe (a pagamento ovviamente).

Dovresti rivedere l'accordo con lui (se ne hai) e chiarire queste cose. Se paga completamente i server e hai creato il sito Web con tutti i diritti trasferiti al cliente, non vedo il motivo per cui non dovresti concedergli le credenziali in quanto in pochi anni potresti essere occupato con un altro progetto e può trovare un'altra società che ci lavora. Se si paga per il server, è possibile creare un account SQL dedicato con diritti di amministratore limitati (ad esempio impedire il rilascio delle tabelle o del database ), poiché è il tuo server e non vuoi esporre a inutili rischi per la sicurezza. In entrambi i modi, assicurati sempre di avere un backup giornaliero.

Idealmente, se stai creando il sito web con tutti i diritti trasferiti al cliente, dovresti fornire tutte le credenziali necessarie durante il passaggio di consegne in modo formale al completamento del progetto (un file Word o un documento stampato), o puntare a il software giusto per gestirli (ad es. password manager, KeePassX o file crittografato, Keybase, Ansible Vault, ecc.). Gestendo questi dettagli, dovrebbe accettare il rischio, e non dovresti essere più responsabile per quanto hai fatto per proteggere questi dettagli.

Concordo pienamente sul fatto che se è serio e non prende il tuo primo "no" per una risposta, devi dargli una risposta completa per iscritto, di cui conservi una copia ben documentata e sicura su un sistema impossibile accedere.

Nella tua risposta, vorrei riassumere i motivi per cui non dovrebbe usare le credenziali di root e forse un riferimento a qualcosa di ufficiale (blog, link, libro, white paper) per dimostrargli che la tua raccomandazione è una pratica standard .

Infine, gli offri di consegnargli una busta sigillata, da conservare in una cassastrong o in una banca, con le credenziali. Se (come si spera) non insiste, come è convinto, sembra ancora buona pratica che le credenziali siano disponibili da qualche parte, nel caso in cui qualcosa ti capiti (o anche quando sei in congedo), ed è imperativo che qualcuno possa intervenire.

Essere l'unica persona con credenziali di root; o usarlo come potenziale problema di ricatto / contrattazione, è, secondo me, una cattiva pratica, non etico, e dà agli sviluppatori (o qualsiasi cosa tu sia) un brutto nome.

Per la cronaca, questa richiesta concretamente viola il privilegio minimo (non solo può). Gli altri poster qui sono tutte buone risposte. Nella tua posizione, personalmente proverei a dissuadere il fondatore. Se ciò non funziona, lo consiglierei sui rischi di accesso al database e, supponendo che lo voglia ancora, concedilo a lui (nel modo più limitato possibile).

Come tutti gli altri hanno detto, avrei documentato l'intero processo, includendo consigli sui rischi e il consenso informato. A seconda della natura dei dati, prenderei in considerazione l'opportunità di coinvolgere il consulente legale della società.

Nonostante il modo in cui tende a comparire per molte persone nei campi aziendali, l'accesso come root a un database è una cosa seria. Può avere implicazioni legali, implicazioni tecniche e potenzialmente causare enormi danni di una varietà di tipi. Lo sappiamo tutti, ma non tutti lo fanno, e quindi spiegare la serietà è una parte importante di ... prenderlo sul serio.

Inoltre, ancora una volta per la gente nella fila posteriore perché è una grossa delusione: documenta tutto.