Qué DBMS es apropiado para mantener un esquema privado incluso cuando está instalado 'en la naturaleza'

Question

Tengo un servidor de aplicaciones que se conecta a un servidor de base de datos. Me gustaría poder proporcionar a los usuarios instaladores y, con un grado moderado de comodidad, confiar en que el esquema de la base de datos es seguro.

Entiendo que hay algunos riesgos que tendré que aceptar al no controlar la computadora en la que se instaló: una persona determinada con las herramientas y el conocimiento adecuados podría mirar directamente a la memoria y extraer información.

Inicialmente pensé que mi área de enfoque sería simplemente agregar las credenciales al instalador sin que se vean trivialmente en un editor hexadecimal.

Sin embargo, cuando comencé a investigar, aprendí que para PostGreSQL, incluso si instalo la base de datos de manera silenciosa y no proporciono las credenciales al usuario, simplemente pueden cambiar un archivo de configuración basado en texto (pg_hba.conf ) y reinicie el servidor, permitiendo el acceso completo a la base de datos sin credenciales.

¿Este escenario está asegurado en otros DBMS? ¿Cómo protegen la mayoría de los productos comerciales sus esquemas en este escenario? ¿La mayoría de los productos usarían bases de datos integradas?

---

Editar: supongo (tal vez erróneamente) que algunos productos se basan en bases de datos que el usuario nunca toca directamente. Y, por supuesto, nunca los veo porque lo han diseñado de tal manera que el usuario no lo necesita, probablemente utilizando una base de datos integrada.

Answer 1

La mayoría de los productos comerciales no protegen sus esquemas. Se dividen en uno de los dos campos:

O están haciendo uso de una base de datos de clase empresarial para un componente clave del producto (como un sistema de nómina), en cuyo caso no se intenta ocultar el esquema / datos. En la mayoría de estos casos, el cliente necesita control sobre la base de datos de todos modos: para configurar cómo se realiza una copia de seguridad de la base de datos, para poder crear un entorno agrupado, etc.

El otro caso es si su " base de datos " no es más que una pequeña configuración o un archivo de almacenamiento para una aplicación de escritorio (por ejemplo, el historial y las bases de datos de marcadores en Firefox). En ese caso, solo debe usar una base de datos integrada (como SQLite, igual que FireFox) y agregar una capa de cifrado de transmisión (hay una versión oficial de esto llamada SEE), o simplemente usar la base de datos integrada y olvidarse de la capa de cifrado, ya que el usuario tendrá que instalar sus propias herramientas de base de datos para leer el archivo en primer lugar.

Answer 2

Por lo que recuerdo, no hay productos comerciales que " protejan " sus esquemas. ¿De qué quiere que se proteja el esquema?

Considere los siguientes puntos:

• Después de todo, la única persona que puede proteger algo en un RDBMS es el administrador del servidor de la base de datos. ¿Y quieres que el esquema esté protegido contra esta persona?

• Si fuera un cliente y tuviera mis datos dentro de su esquema, no solo me gustaría, sino que esperaría, poder verlos y consumirlos directamente.

• ¿Realmente necesita proteger su diseño relacional? ¿Es realmente tan interesante? ¿Has inventado algo que valga la pena esconder? Realmente no lo creo. Y me disculpo de antemano si es así.

---

EDITAR: comentario adicional:

No me importan la mayoría de los componentes internos de la base de datos para los productos que uso. Esa es otra razón por la que creo que la mayoría de ellos no toman ninguna medida para protegerlos. La mayoría de ellos no son tan interesantes.

Por un lado, creo firmemente que los usuarios no deberían necesitar saber o preocuparse por las partes internas de la base de datos. Pero al mismo nivel, como desarrollador, no creo que valga la pena tratar de protegerlos. Escondiéndolos del usuario, sí. Protegerlos contra el acceso directo, en la mayoría de los casos, no. Y no porque piense que está mal proteger tu esquema. Es porque creo que es algo muy difícil de hacer, y no vale la pena su tiempo como desarrollador.

Pero al final, como con cualquier tema relacionado con la seguridad, la única respuesta correcta es sobre cuáles son los riesgos frente a los costos de implementar la medida de seguridad.

Los motores de base de datos actuales, integrados o de estilo servidor, no están diseñados para ocultar fácilmente el esquema de la base de datos y, por lo tanto, el costo de desarrollo de hacerlo es mucho mayor que el riesgo involucrado, para la mayoría de las personas.

Pero su caso podría ser diferente.

Answer 3

¿Qué problema estás tratando de resolver? Nada puede impedir que el DBA * haga lo que quiera con las bases de datos estándar, y como otros han señalado, es activamente hostil interferir con las necesidades específicas del sitio, como las copias de seguridad y las actualizaciones de la base de datos. A lo sumo, puede cifrar el contenido de su base de datos, pero incluso así debe proporcionar una clave de descifrado para que su aplicación se ejecute realmente y un DBA motivado y hostil probablemente pueda subvertirlo.

Las comunidades militares y de inteligencia indudablemente tienen bases de datos donde incluso el esquema está altamente clasificado, pero no sé si están protegidos por medios técnicos o simplemente por hombres grandes con armas de fuego.

(*) DBA o administrador del sistema capaz de modificar archivos como pg_hba.conf.

Answer 4

  

¿Cómo funcionan la mayoría de los productos comerciales?   proteger sus esquemas en este   escenario?

No creo que la mayoría de los productos comerciales hagan nada para proteger sus esquemas.

Answer 5

¿Cómo un DBMS incrustado puede evitar que alguien juegue con su almacenamiento (archivos en este contexto de hardware no incrustado) cuando dicha persona tiene acceso físico a la máquina donde se ejecuta este DBMS? La seguridad a través de la oscuridad es una propuesta arriesgada.

Answer 6

Esta idea sufrirá los mismos problemas que DRM. No puede evitar el acceso por parte de un determinado, y solo causará dolor y sufrimiento general a sus clientes. Simplemente no lo hagas.

SQLite envuelve todo su formato de base de datos en un solo archivo, y posiblemente podría cifrarlo y descifrarlo en el lugar. La falla, por supuesto, es que los usuarios necesitan la clave para usar la base de datos ahora, y la única forma en que puede suceder es si se la das, tal vez codificándola en tiempo de compilación (seguridad por oscuridad) o un esquema de teléfono residencial (una gran cantidad de razones por las cuales esta es una mala idea). Además, ahora te odiarán porque has frustrado cualquier intento de un sistema de respaldo útil y obtienen un rendimiento terrible al arrancar.

Además, a nadie le importan los esquemas. Odio decírtelo, pero el diseño del esquema no es un problema difícil, y ciertamente nunca es una ventaja competitiva legítima (fuera de quizás algunas áreas específicas como la representación del conocimiento y el almacenamiento de datos). En general, no vale la pena proteger los esquemas en primer lugar.

Si realmente es tan importante para usted, haga una aplicación alojada en su lugar.