prevención de acceso a la base de datos MySQL

2

Estoy haciendo un sitio web de PHP para un cliente que se ocupa de información financiera de terceros, y le preocupa que los desarrolladores (yo) tengan acceso a toda la información, lo que obviamente es una preocupación válida.

Actualmente estoy alojando en un entorno de alojamiento compartido, sin embargo, voy a recomendar un servidor dedicado para este sitio.

Puedo incluir todo tipo de registros en el código fuente del sitio y hacer que el código sea auditado antes de que se inicie el sitio, por lo que debería evitar que las puertas traseras del código filtren información. Sin embargo, me preocupa cómo evitar el acceso a phpMyadmin u otras herramientas administrativas para acceder directamente a la base de datos.

¿Por dónde empezar a sacar esta preocupación del camino? Cualquier consejo será apreciado.

Gracias de antemano!

    
pregunta Kobus Myburgh 27.03.2013 - 09:58
fuente

3 respuestas

0

PCI-DSS es el estándar de la industria que se aplica a la mayoría de los sitios web comerciales que tratan transacciones financieras, por lo tanto, debería poder encontrar los protocolos exactos que exigen los PCI DSS en su documentación y puede basar su propio sistema.

Si bien entiendo su preocupación de que el desarrollador tenga acceso a datos financieros, la confianza es un tema clave aquí. La confianza a un lado de los datos financieros debe estar lo suficientemente encriptada para garantizar que, en caso de un volcado directo de la base de datos, no se filtren datos financieros de texto simple. Esto requerirá que el código fuente de su aplicación (que contenga políticas clave, etc.) o la aplicación en sí esté comprometida.

En cuanto a la prevención de phpMyAdmin y otras herramientas del acceso directo a la base de datos, simplemente puede cambiar la raíz de MySQL y otras contraseñas a través de la línea de comandos en MySQL. Esta es una forma burda, pero dejará a phpMyAdmin sin poder sincronizarse con MySQL. Cambiar el puerto predeterminado de MySQL también es una alternativa secundaria en un servidor dedicado.

Sin embargo, un enfoque más probado es el implementado por sistemas como SAP, mientras que evita que los programadores accedan directamente a la base de datos para evitar daños a la integridad de los datos almacenados. Lo hacen restringiendo las aplicaciones a un único inicio de sesión de usuario de la base de datos, cuya contraseña solo corresponde a la aplicación. Si cualquier otro usuario de la base de datos intenta acceder a los datos almacenados, el intento se registra e informa, lo que generalmente hace que cualquier garantía se considere nula.

    
respondido por el Rohan Durve 27.03.2013 - 13:23
fuente
3

Hay una serie de controles que podría implementar aquí para brindar al cliente algo de comodidad sobre la seguridad de sus datos. Parte de esto podría ser una exageración dependiendo del cliente, pero no obstante, las ideas

  • Asegúrese de que el cliente establezca todas las contraseñas del sistema (por ejemplo, cuentas del sistema operativo, MySQL) para el sistema de producción
  • Suponiendo que este sistema estará en un proveedor de alojamiento en lugar de estar en el sitio del cliente, podría considerar la configuración de reglas de Firewall a nivel del sistema operativo y archivos .htaccess en el nivel del servidor web para restringir dónde se pueden hacer las conexiones desde para herramientas administrativas (por ejemplo, SSH, phpmyadmin). Esto requeriría que el cliente tenga una dirección IP fija que pueda usarse para este propósito.
  • Proceso de cambio documentado. Un riesgo aquí sería que una actualización de código agregue algo desagradable, por lo que si desean una garantía continua, necesitarían tener un proceso de implementación definido en el que el cliente ponga en producción cada versión (suponiendo que solo ellos tengan acceso)
  • Registro y supervisión. A nivel de sistema operativo, podría registrar toda la actividad más información

Todo esto, por supuesto, depende de la idea de que el cliente tiene el conocimiento y los recursos para administrar el servicio. Si no lo tienen y aún tiene acceso de administrador, entonces realmente es una situación de confianza, ya que si tiene acceso de raíz a la caja o la base de datos, puede obtener copias de los datos.

    
respondido por el Rоry McCune 27.03.2013 - 10:14
fuente
0

Su caso, si lo he leído bien, es uno clásico que trata los problemas de derechos y permisos para el código que se ejecuta en producción.

primero como desarrollador principal de seguridad de ninguna manera debería tener acceso al código que se ejecuta en producción. Aquí es donde entra el cinceps de libirarian. Todo el código después de las pruebas va al estándar y luego se muda de allí.

En segundo lugar, una vez allí, puede dejar que los administradores de sistemas del equipo técnico de su cliente se encarguen de quién se encarga del mantenimiento de rutina.

En tercer lugar, dependiendo de la sensibilidad y la clasificación de los datos, debe probar o proporcionar la seguridad necesaria de que su sistema controla la efectividad para bloquear accesos no autorizados. El control de acceso debe ser impulsado por los requisitos del cliente.

El registro es un control de detección que necesita para comenzar a pensar en las líneas de seguridad preventiva.

    
respondido por el Saladin 27.03.2013 - 15:22
fuente

Lea otras preguntas en las etiquetas