Should company protect DB schema at the same level of the data itself?

Question

If a company holds DBs that has access to different users. If the company has to decide how much to invest in protecting the data itself and how much to protect the DB schema (the structure and inner relations between tables and fields). Should the company invest only on protecting the data itself? Is there any threat for DB schema penetration. Is the schema has valuable meaning at all or can it increase the DB vulnerability for future attacks?

Answer 1

No

Protection of the database schema is a type of security by obscurity.

Your software should be designed and configured in such a manner that none of its security is compromised when a hacker learns its design. In fact, in the best case your design is made public so that security professionals can critique it and you can continuously improve it.

Answer 2

@John-Wu's is the right answer, investment should not be made to prioritize protection of schema above protection of the data.

Data is most important and is a compromise target for attackers. Schema is at best an information leak.

That said, databases themselves typically treat schema metadata at a different and higher privilege level than the data, not without reason. As @marcus-muller says, schema provides attackers with useful hints. And a user with privileges to see schema can almost always see data, while users with privileges to see data may not be able to see schema.

So schema should not be considered unnecessary to protect. But data is most important.

Answer 3

Although I agree with @JohnWu's answer that Security By Obscurity is a bad concept, there's one thing:

Yes. In a way.

Complex database schemes typically have complex relations. But let me come up with a simply example:

You've got a table

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

Where ID is an auto-increasing primary key, CustomerNo refers to the primary key of your customer table, and Order refers to the primary key of your order table. This way, you map your orders to customers.

You, of course, only let each customer see the rows that "belong" to themselves.

Still, do you see the problem?

Exactly, through the linearly increasing ID field, customer 1 has an easy way of figuring out when the competition does their orders, simply by not acting like a "normal" customer, placing orders in bulks, but by automatedly placing orders every minute.

That way, they figure out that every Tuesday afternoon at 4:30pm, the competition orders. Now, knowing the market for hardware very well, they put a big sell option on the market every Tuesday 4:20pm, thus increasing the market price of nuts, harming their competitor, and also, financially profiting from knowledge they should never have gotten in the first place.

This is a question of data cleanliness, in principle. A monotoneous primary key gives you (partial) information you shouldn't have. Hence, your customer API would need to make sure the information leakage is zero. And I mean that mathematically: Information has a pseudo-unit, bit, and there's a whole mathematical discipline called information theory, that describes how much information is in the observation of a certain event based on randomness (for example, if there's more than two customers in that table, you can't know which of your competitors did the ordering at 4:30pm, but you still get probabilities out of this, and hence, non-zero information).

It's very unlikely you can hide such information from your customers if they have access to the database scheme. In fact, that scheme doesn't help them without you giving them info they probably shouldn't be getting. In that sense, well, your scheme doesn't need to be secret, but some of the data that you probably still only consider "relational" within a customer's accessible records should, in fact, be secret from the customer.