El fundador de negocios quiere acceder a la base de datos pero no tiene habilidades de base de datos

Él es el propietario de los datos . No tú. Si eres golpeado por un autobús, necesitará acceso. Absolutamente debes darle acceso. Esta solicitud no es una sorpresa en absoluto. Si construyes un sitio web para mí, te preguntaría lo mismo.

BUT , y esta es la parte importante, tampoco puedes competir con él por la administración de la base de datos. Tú eres el administrador, no él. Él tiene acceso, pero no puede usarlo. Una vez que lo hace, entonces eres absuelto de la responsabilidad de la base de datos. Este bit lo necesita por escrito y debe ser entendido claramente. Y luego necesitas registrar su acceso.

Estoy completamente de acuerdo en que no deberías luchar por el acceso de la raíz, pero aún así puedes proporcionar el acceso del Propietario de datos sin competir por el control.

He estado en esta posición un millón de veces. Simplemente explique que podría romper algo inadvertidamente si no tiene cuidado y darle los inicios de sesión, ya que es suyo. Asegúrate de hacer un volcado de db antes para que puedas restaurarlo si lo rompe (por una tarifa, por supuesto).

Debes revisar el acuerdo con él (si tienes) y aclarar esas cosas. Si él paga por completo los servidores y usted ha creado el sitio web con todos los derechos transferidos al cliente, no veo la razón por la que no debería darle las credenciales, ya que en pocos años podría estar ocupado con otro proyecto. , y puede encontrar otra empresa trabajando en ello. Si paga por el servidor, puede crear una cuenta SQL dedicada con derechos de administrador limitados (por ejemplo, evitando que se eliminen las tablas o la base de datos). ), ya que es su servidor y no desea exponerse a riesgos de seguridad innecesarios. En ambos sentidos, siempre asegúrese de tener una copia de seguridad diaria.

Idealmente, si está creando el sitio web con todos los derechos transferidos al cliente, debe proporcionar todas las credenciales necesarias durante la entrega de manera formal al finalizar el proyecto (un archivo de Word o un documento impreso), o apuntar a el software correcto que los maneja (por ejemplo, administrador de contraseñas, KeePassX o archivo encriptado, Keybase, Ansible Vault, etc.). Al manejar estos detalles, debe aceptar el riesgo y usted ya no debe ser responsable en la medida en que hizo todo lo posible para garantizar estos detalles.

Totalmente de acuerdo en que si es serio y no acepta su primer "no" como respuesta, debe darle una respuesta completa por escrito, de la cual guarda una copia bien documentada y segura en un sistema. no puedo acceder.

En su respuesta, resumiría las razones por las que no debería usar las credenciales de root, y quizás una referencia a algo oficial (blog, enlace, libro, libro blanco) para demostrarle que su recomendación es una práctica estándar. .

Finalmente, le ofreces que le entregue un sobre cerrado, para que lo guarden en una caja fuerte o en un banco, con las credenciales. Si (como es de esperar) no insiste, como está convencido, todavía parece una buena práctica que las credenciales estén disponibles en algún lugar, en caso de que algo le suceda (o incluso cuando esté de permiso), y es imperativo que alguien pueda intervenir.

Ser la única persona con credenciales de root; o usarlo como un posible problema de chantaje / negociación, es, en mi opinión, una mala práctica, poco ético, y le da a los desarrolladores (o lo que sea que sea) un mal nombre.

Para el registro, esta solicitud viola concretamente el menor privilegio (no solo puede). Los otros carteles aquí son todas buenas respuestas. En su posición, yo personalmente trataría de disuadir al fundador. Si eso no funciona, entonces le aconsejaría sobre los riesgos del acceso a la base de datos y, suponiendo que todavía lo quiera, se lo conceda (de la forma más limitada posible).

Como todos los demás dijeron, documentaría todo el proceso, incluido el asesoramiento sobre riesgos y la recepción de su consentimiento informado. Dependiendo de la naturaleza de los datos, consideraría la participación de los asesores legales de la empresa.

A pesar de la forma en que suele aparecer para muchas personas en los campos comerciales, el acceso de raíz a una base de datos es algo serio. Puede tener implicaciones legales, implicaciones técnicas y potencialmente causar enormes daños de una variedad de tipos. Todos lo sabemos, pero no todos, y por eso explicar la seriedad es una parte importante de ... tomarlo en serio.

También, una vez más para la gente que está en la última fila porque es algo importante: documenta todo.