Considere una red para una aplicación web con 1 servidor web y 1 base de datos MySQL, tanto en servidores físicamente diferentes como en Linux. La base de datos almacena datos de misión crítica y estos datos son y deben ser manipulados por el servidor web.
Ahora, obviamente, queremos asegurarnos de que solo se realicen cambios autorizados en esta base de datos. Esto se implementa en gran medida en la aplicación y una parte se maneja creando usuarios de bases de datos con cantidades limitadas de autorizaciones.
Sin embargo, aún quedan lagunas con este enfoque. Por ejemplo: el administrador del sistema no está autorizado a realizar cambios en la base de datos de forma independiente. Tampoco los ingenieros con derechos de despliegue. Pero, obviamente, podrían hacerlo al tomar las credenciales de la base de datos del servidor web e iniciar sesión desde allí.
Cualquier cambio realizado de esta manera sería básicamente anónimo, ya que se verían oscurecidos por muchos otros cambios que dificultarían su detección.
Es (probablemente) no es factible o prudente implementar algo que en realidad 100% evitará que el administrador del sistema pueda realizar cambios de esta manera. Sysadmin y otros deben poder realizar cambios de datos y esquemas utilizando sus propias cuentas a medida que la aplicación se desarrolla activamente. Sin embargo, no deberían poder hacerlo sin que nadie se dé cuenta.
Aquí hay algunas estrategias posibles para evitar que los usuarios internos cambien los datos de forma anónima:
-
Implemente el registro de auditoría en el sistema para informar sobre cualquier programa ejecutado. Esto encontraría cualquier llamada directa a
mysqlcli y tal vez algunas secuencias de comandos de aspecto incompleto. Cualquier cambio realizado con éxito aún sería difícil de encontrar, ya que las secuencias de comandos ocultan los cambios realizados. -
Use certificados de cliente en la conexión de la base de datos con frases de contraseña en la clave privada. Esto significa que un administrador del sistema ya no puede reiniciar una máquina sin la presencia de un administrador de aplicaciones. Probablemente se necesiten otros controles para proteger las claves en la memoria, siendo sysadm root y todo.
-
Implementar el registro de auditoría en la base de datos. La aplicación web causa una cantidad significativa de tráfico en la base de datos, por lo que es poco probable que se detecten cambios maliciosos en el usuario de la base de datos de la aplicación. Esto significa que el monitoreo solo puede implementarse de manera factible para usuarios de bases de datos interactivas.
-
Use IPTables para bloquear el tráfico de la base de datos al usuario de la aplicación. Al menos crearía un seguimiento de auditoría de sysadmin convirtiéndose en el usuario de la aplicación (sudo) o cambiando el firewall para permitir el tráfico. No es infalible, ya que cualquier cambio realizado con el usuario de la base de datos de la aplicación aún sería difícil de encontrar.
-
Implemente SELinux para limitar el tráfico de la base de datos (etiquetado de paquetes a través de SECMARK) al dominio de la aplicación y además asegurar la implementación y crear cadenas para evitar / detectar cambios no autorizados. Si sysadmin necesita acceso de red a la base de datos, esto puede ser auditado a través de
auditallowpero el acceso administrativo debe ser a través de otro usuario auditado. Cualquier cambio en el sistema o cambios en SELinux serán alertados. Esto obviamente es un cambio de alto impacto con muchos requisitos adicionales que requieren mucho conocimiento.
Más allá de simplemente confiar en el administrador de sistemas, ¿cómo usted se aproxima a esto? ¿Funcionarían las cosas anteriores? ¿Qué otras cosas se podrían hacer para asegurarse de que un administrador del sistema o un usuario con privilegios similares no pueda acceder a la base de datos sin ser detectado?