Question Opinions wanted on DB security

[irish634]

Hello everyone.

I am in the middle of creating a security module that can be used in any Access database.

Where I am now is changing the database properties (Allowing tool bar changes, Allowing the bypass key, etc).

Do you think it's beneficial to have these properties in a table and allow them to be defined by a user with "admin" privileges? Or, for security purposes, should I just set them and basically make the users deal with it?

Keep in mind, I may be developing the database, but I may not be the administrator or programmer once the application is turned over.

(For safety I was thinking of putting in a module to "reset" the values to a predetermined default, in the event something goes awry.)

Another option is to have a command button to change each individual property.

What's the general consensus?

Thanks,
Craig

 

[Banana]

First, you need to define the threat model. That is, who are you worried about that will hack into your security? Are we talking about diehard hacker who would want to sell off private information and engage in identity thefts? Or are we talking about a sneaky office worker who want to look as if he's doing more work than everyone else by modifying data? Or are we wanting to keep out the honest but ignorant folks out of design view of the database?

The model then needs to encompass the environment as well. Will it be across WAN? Or is it going to be always confined to an office LAN behind a firewall? Or is it for a subnet? Or maybe it's just on your computer and others can access a shared folder?

Once you've evaluated the model accurately, then it's easier to come up with a sane security model that does not only encompass the database security but also the Windows security, network security and just about anything else.

The above module proposed will depend a lot on the model you have. If you all want to do is prevent honest workers out, then it may work OK. But if there's a bastard in your office who will go to any length to circumvent the security so he can cook his books, then it's inadequate.

 

[irish634]

First, you need to define the threat model. That is, who are you worried about that will hack into your security? Are we talking about diehard hacker who would want to sell off private information and engage in identity thefts? Or are we talking about a sneaky office worker who want to look as if he's doing more work than everyone else by modifying data? Or are we wanting to keep out the honest but ignorant folks out of design view of the database?

The model then needs to encompass the environment as well. Will it be across WAN? Or is it going to be always confined to an office LAN behind a firewall? Or is it for a subnet? Or maybe it's just on your computer and others can access a shared folder?

Once you've evaluated the model accurately, then it's easier to come up with a sane security model that does not only encompass the database security but also the Windows security, network security and just about anything else.

The above module proposed will depend a lot on the model you have. If you all want to do is prevent honest workers out, then it may work OK. But if there's a bastard in your office who will go to any length to circumvent the security so he can cook his books, then it's inadequate.

Thanks for the answers. Makes a lot of sense. Basically, I don't have any "bastards" per se. It's the people that know just enough about access to get to tables, etc to possibly edit data. Meaning most of these people only know about using the shift key and that sort of thing. Generally, if they can't get to the database window, and tables, they'll give up. I know there are a lot of holes in this, but for my threat model, I am only concerned with what I have mentioned. If someone were to circumvent the database security items, it wouldn't be that difficult to pinpoint the culprit given our existing network security and setup

The application will most likely be used on an office network where multiple users can use the database at once.

 

[Banana]

Here's one way you can ensure that the setting for disabling shift keys and the like are always enforced:

1) Use a startup form and on its open event, set the properties as you have done in the module.

2) Use User-Level Security, and do make database owned to an account other than Admin, but give the default user Admin permission to open/run database, some forms. If you don't mind the extra work, deny the permission to tables and make queries "Run With Owner's Permissions", and grant only permission to run the queries. (I can't remember if you can open a form and run the queries that you don't have permission to run directly).

3) Compile into MDE for distribution.


This way, security from the end users' perspective is unchanged, there's no log on or so, but they couldn't do anything because there's no access to design view which they need to have to turn off the code you've placed, and MDE makes it impossible to alter the startup form and the like.

Or a more simpler approach is to put the code in a module and lock it up requiring a password. I can't remember if you indeed can lock up code behind forms but if it can be done, then that's one option without having to setting up the ULS.

HTH.

 

[The_Doc_Man]

So, basically, you are looking at protecting users from themselves by making changes in an unaudited or unfiltered way. You are protecting yourself from the lazy users who know enough to reach in and touch what they want if only you would allow it.

Banana's discussion was quite good. In that light, if my two statements above are correct, then your model is "keep the undisciplined users from doing anything undisciplined" - as opposed to "make this sucker bullet-proof."

This is where a workgroup's role-based security setup works ok, and where it makes sense to have a switchboard form to call up other possible action-related forms. If any queries are involved, read-only access to the tables would work, having the forms that do changes use a different query and the feature to run that query not as the user but as the owner of the query.

You would never let the users see the database window in that case. You would also disallow creation of queries.

Here's the catch: If your application requirements include a statement of users being able to write ad-hoc queries, the above is not quite so simple anymore. That's a garden path more like the maze from "Harry Potter and the Goblet of Fire."

 

[irish634]

So, basically, you are looking at protecting users from themselves by making changes in an unaudited or unfiltered way. You are protecting yourself from the lazy users who know enough to reach in and touch what they want if only you would allow it.

Banana's discussion was quite good. In that light, if my two statements above are correct, then your model is "keep the undisciplined users from doing anything undisciplined" - as opposed to "make this sucker bullet-proof."

This is a perfect synopsis of what the end goal is.

Using the work groups is also one of my options. Part of what I have been asked to do is set the databases up so that:

1. The user creating the record is logged.
2. The user editing the record is logged.
3. I don't know why - but there is a wish to run database statistics where all usage data is compiled and reported. Kind of like labor tracking I assume. If you ask me though, it's kind of useless data but I don't sign my own paychecks LOL!

So the "undisciplined" security will include those items. Based on what you two have suggested, I think I have a pretty good idea for what I want/need to do for this. Thanks.

 

[Alisa]

http://allenbrowne.com/AppAudit.html

Have you seen this link? This method will take care of logging record changes.

 

[irish634]

http://allenbrowne.com/AppAudit.html

Have you seen this link? This method will take care of logging record changes.

Yes, I am actually doing something very similar to this.