¿Debería la empresa proteger el esquema de base de datos al mismo nivel de los datos?

@ John-Wu's es la respuesta correcta, no se debe invertir para priorizar la protección del esquema por encima de la protección de los datos.

Los datos son los más importantes y son un objetivo de compromiso para los atacantes. El esquema es, en el mejor de los casos, una fuga de información.

Dicho esto, las bases de datos suelen tratar los metadatos del esquema en un nivel de privilegio diferente y superior al de los datos, no sin razón. Como dice @ marcus-muller, el esquema proporciona a los atacantes sugerencias útiles. Y un usuario con privilegios para ver el esquema casi siempre puede ver los datos, mientras que los usuarios con privilegios para ver los datos no pueden ver el esquema.

Por lo tanto, el esquema no debe considerarse innecesario para proteger. Pero los datos son los más importantes.

No

La protección del esquema de la base de datos es un tipo de seguridad por oscuridad .

Su software debe diseñarse y configurarse de tal manera que su seguridad no se vea comprometida cuando un hacker se entera de su diseño. De hecho, en el mejor de los casos, su diseño se hace público para que los profesionales de seguridad puedan criticarlo y usted pueda mejorarlo continuamente.

Aunque estoy de acuerdo con la respuesta de @ JohnWu de que Security By Obscurity es un mal concepto, hay una cosa:

Sí. En cierto modo.

Los esquemas de bases de datos complejas suelen tener relaciones complejas. Pero déjame dar un ejemplo simple:

Tienes una mesa

+----+------------+-------+
| ID | CustomerNo | Order |
+----+------------+-------+
|  0 |          1 |  Nuts |
|  1 |          1 | Bolts |
|  2 |          2 |  Nuts |
|  3 |          1 |  Wire |
+----+------------+-------+

Donde ID es una clave principal que aumenta automáticamente, CustomerNo se refiere a la clave principal de su tabla de clientes, y Order se refiere a la clave principal de su tabla de pedidos. De esta manera, asigna sus pedidos a los clientes.

Usted, por supuesto, solo deja que cada cliente vea las filas que "pertenecen" a sí mismos.

Aún así, ¿ves el problema?

Exactamente, a través del campo de ID que aumenta linealmente, el cliente 1 tiene una manera fácil de averiguar cuándo la competencia hace sus pedidos, simplemente no actuando como un cliente "normal", haciendo pedidos en grandes cantidades, sino haciendo pedidos de forma automática cada minuto.

De esa manera, se dan cuenta que todos los martes por la tarde a las 4:30 pm, la competencia ordena. Ahora, conociendo muy bien el mercado de hardware, ponen una gran opción de venta en el mercado todos los martes a las 4:20 pm, lo que aumenta el precio de mercado de las nueces, perjudica a su competidor y, además, se beneficia financieramente del conocimiento que nunca deberían haber conseguido el primer lugar.

Esta es una cuestión de datos limpieza , en principio. Una clave primaria monótona le proporciona información (parcial) que no debería tener. Por lo tanto, la API de su cliente debería asegurarse de que la fuga de información sea cero. Y quiero decir matemáticamente : la información tiene una pseudo-unidad, un bit, y existe una disciplina matemática completa llamada teoría de la información , que describe cuánta información hay en la observación de un cierto evento basado en la aleatoriedad (por ejemplo, si hay más de dos clientes en esa tabla, no puede saber cuál de sus competidores hizo el pedido a las 4:30 p. m., pero todavía tiene probabilidades de esto, y por lo tanto, no cero información).

Es muy poco probable que pueda ocultar dicha información a sus clientes si tienen acceso al esquema de base de datos. De hecho, ese esquema no les ayuda sin que usted les dé información que probablemente no deberían recibir. En ese sentido, bueno, su esquema no necesita ser secreto, pero algunos de los datos que probablemente aún considere "relacionales" dentro de los registros accesibles de un cliente deberían, de hecho, ser secretos para el cliente.