Drupal Security & Two DBs

No. Sospecho que esta defensa probablemente no sea un gran uso de su tiempo.

Si no tuviera los enlaces, la información sería difícil de usar, difícil de usar para los buenos. Eso es malo para la usabilidad, porque la información no es fácil de usar, probablemente no sea de mucha utilidad para muchos de sus usuarios. Pero los malos no están bajo esas restricciones. Probablemente, los malos aún podrían obtener mucha información confidencial y unir las cosas lo suficiente como para darte un mal día.

¿Recuerdas la historia de los estudiantes revolucionarios iraníes que irrumpieron en la embajada de Estados Unidos en Irán? Los residentes de EE. UU. Destruyeron muchos de sus documentos antes de ser evacuados, pero los estudiantes iraníes aún podían juntar meticulosamente los fragmentos de documentos triturados en un todo, como un rompecabezas. Tuvieron el tiempo y la paciencia para hacerlo. Esos documentos triturados habrían sido bastante inútiles para un legítimo diplomático autorizado de los EE. UU., Pero fueron suficientes para que los atacantes resolvieran una gran cantidad de información confidencial que los EE. UU. No querían que tuvieran. La seguridad es a menudo así; los malos están dispuestos a esforzarse más para recuperar sus datos de lo que lo estaría cualquier usuario normal de su sitio.

Y, en cualquier caso, si su sitio es pirateado, ¿quiere estar en condiciones de decirle a la prensa? "Oh, sí, obtuvieron todos los datos, pero no obtuvieron los enlaces , así que todo está bien? " Eso no suena como el tipo de cosa que va a inspirar confianza entre sus clientes. No es una imagen bonita.

Por lo tanto, te sugiero que gastes tu energía en otro lugar. Recuerde, la seguridad es un esfuerzo de gestión de riesgos. Eso significa que debe priorizar dónde pasa su tiempo, según lo que le ofrezca el mayor beneficio de seguridad por el menor tiempo, energía y costo. No creo que esta defensa sea buena. En su lugar, me concentraría en lo básico, cosas como la seguridad de la aplicación (SDL), la administración de la configuración, la seguridad de la red, la preparación y recuperación de desastres, la educación interna, etc. La mayoría de las organizaciones tienen mucho espacio para mejorar, incluso en lo básico.

Causaría un impacto en el rendimiento. Además, depende de lo que le preocupa haber robado. Es posible que incluso si lo hace, un atacante aún pueda adquirir su lista de clientes y posiblemente información de pago si la está almacenando.

Incluso si los datos no son útiles en su aplicación sin una clave de relación, un atacante probablemente estaría muy contento con los datos no relacionados si esos datos son coherentes de alguna manera.

Teniendo en cuenta la amenaza de 0 días, es absolutamente enloquecedor que se asegure de que cuando se comprometa el sitio, no se robe la base de datos principal. Tampoco se expone como Mat Honan con su dirección y tiene problemas de seguridad tan grandes, al revelar el agujero y al proporcionar la dirección de su sitio web.

Esto se puede implementar sobre la base de un servidor de autenticación externo que mediará la seguridad entre el servidor principal y los nodos.

Si pudiera describir con más detalles técnicos qué está haciendo, podría dibujar un ejemplo.

El servidor de autenticación está utilizando todos los mecanismos de seguridad y tiene una capacidad limitada para servir solo como servicio de recuperación de contraseña y autenticación, por lo que no está expuesto a los ataques remotos comunes de Drupal. También tiene contraseñas cifradas y así sucesivamente. Además, no está expuesto a Internet y tiene un filtrado más estricto. De esta manera, ninguno de los sitios / bases de datos debe ser técnicamente capaz de proporcionarle ningún dato antes de autenticarse en él, y debe proporcionar solo datos a los que tiene acceso, a través de API, acceso directo a la base de datos o clases OO. Esto a veces requiere actualizaciones de DB y código, como esquemas y controles de seguridad, pero primero está bien para asegurarse de que la contraseña de root de MySQL o cualquier otra cosa no se use en ningún otro lugar, y que el inicio de sesión del administrador también se cambie a otra cosa. la administración y la página de acceso solo se sirven con FQDN y también se puede acceder al backend a través de un enlace oculto (por lo que no es visible para la mayoría de los escáneres).