2

In my organization we have database as backend, application servers then web servers and then proxy servers.

I know it is usually best to have security implemented closest as possible to the data and if it is possible to do it in the database it is ideal. Can add the other layers as well as layers of security but that would be in addition.

Can you tell me if I am correct and refer to a credible source that says the same?

schroeder
  • 123,438
  • 55
  • 284
  • 319
j. doe
  • 55
  • 5
  • 1
    I think you need to be clear about what *specifically* you want to secure and what level of 'security' you deem to be a given. Putting in a firewall is not as important as putting a password on the db admin account, but those 2 actions are meant to secure completely different things. – schroeder Jan 29 '17 at 08:14
  • It is a .NET web application (web) using lots of libraries that was once used in a winforms application and got extended over the years (application). And the users are able to query and edit tables in the backend via this web interface. I can go to the application tier (where many of the business logic is) and do it there or do it in any other tier – j. doe Jan 29 '17 at 10:47

1 Answers1

1

best to have security implemented closest as possible to the data (...) in the database it is ideal.

Why? What? Where? How?

No, the idea that you want to safeguard data has nothing to do with the data layer (e.g. database) in a layered application. In the vast majority of cases that would a terribly bad thing to do.

The idea that you want to safeguard the data is the reasoning where you place the safeguards where the data is kept and processed in each layer of the application (including the database layer if the given data to be safeguarded lies there). If any layer of your application that can perform data requests is compromised then it will bypass the safeguards in the lower layers.

For a simple example: if you have an application where the database access is protected with a password and the application layer stores and reuses that password on connections, then compromising your application layer is all it takes.

Addendum

A scenario where the idea that safeguards shall be close to the database makes some sense is an application layer that can process encrypted data. For example, where the data is stored encrypted in the database and operations that use this data are performed externally (e.g. in an HSM).

grochmal
  • 5,677
  • 2
  • 19
  • 30
  • This answer seems to be indicating that it is inappropriate to use database permissions to segregate two or more separate back ends that perform different operations on different data (or ignoring the scenario). Additionally, enforcing permissions in the app back end or in the db is a design decision that depends heavily upon the design and purpose of the app, itself. Just because many apps don't use the db's permissions model as the app's permission model, that doesn't mean it's the case or appropriate for all apps. – atk Jan 29 '17 at 05:50
  • @atk - hmmm... It might. But the purpose was the contrary: to argue that even the best database credentials mean nothing if the data that leaves the database is not looked after. I've made a tweak to the second paragraph to include the use of database measures, i hope it does not look that application centric now. – grochmal Jan 29 '17 at 06:16
  • thanks @grochmal so it would be perfectly alright to have an application user with read write permissions to all SQL Server databases as long as the ASP.NET website takes care of who should see what? No advantage in setting up connection so SQL knows who the user is? – j. doe Jan 29 '17 at 10:29
  • @j.doe Ekhm.. no. By the contrary. The point is that if there is a single place where data exists and is not protected then all other safeguards are useless. e.g. if you make a castle and fortify 3 sides of it the enemy will attack from the fourth ('cause he isn't stupid), and all your walls are useless. – grochmal Jan 30 '17 at 01:04