Question DB security without MDW - good idea or not?

henkus

Registered User.
Local time
Today, 03:37
Joined
Jun 4, 2008
Messages
14
Hi,

Acess2003
Multiuser enviroment

Objective:
Maintain an Access database, which is highly secured for normal users, while still having admin possibilities. Single sign-on would be nice, but I guess not absolutely necessary.

Being quite new on Access, but with some experience with VB, I choose this concept when designing the security for my first bigger Access DB (I've later learned that it's probably a bit unconventional):

* MDB-file is pwd-protected (this is Admin login I suppose), known by all user that have read/write access to the folder where the DB-file is located.
* I have no MDW-file -> no groups or users maintained in the DB.
* I've unchecked everything possible in the startup options (and disabled the shift key),. and a switchboard form opens on startup.
* Upon opening DB, function checks the Active directory, and depending on which group the user is in assigns a "Userlevel" to the session.
* Depending on userlevel, different buttons are shown on main switchboard, leading to different reports and forms.
* If admin userlevel, button is visible that can enable the shift-button, thus enabling editing forms and such.


Questions:
* Does this sound like a reasonably good concept or not?
* If no, what should I absolutely do differently?
* What possibilities does there exist to access the data in the DB even though you're not in the correct group? Example: Table A has three columns. Form B displays some records in this table. If user has userlevel=1, all columns are shown. If userlevel=2, column C is hidden. Do you see any ways the user in userlevel 2 can work around this limitation?)
* Is the database secured against external connects? (Example: Can someone create another DB, that connects to my DB (with VB for example) and extract information to his unsecured DB? - if yes, how do I protect against it)

Thank you very much in advance!
 
Simple Software Solutions

Because you have a password to open the database in the first instance anyone who is attemptiing to import the data froom an external mdb will have to provie the password. So in this instance you data is secure.

With regard to conditional formatting of columns dependant on access levels you would have to code this within the form, I suspect.

You have not mentioned as to whether this is a split database with a FE/BE setup. Again I suspect it is by the content of the post.

Another safeguard you could employ is to protect your code by designing a form or a module and going to Tools, "Database Name" Properties and click on Protection. You can password protect your code so if anyone has actually bypassed you initial security they are prevented from accessing your code.

Again you could create an MDE from the MDB and deploy that as a further means of protection. My only misgiving with MDE's is that should an error occur, whether it be syntactical, logical or data driven you will only get an error message stating an error has occured without any explanation as to the nature of the error.

CodeMaster::cool:
 
Because you have a password to open the database in the first instance anyone who is attemptiing to import the data froom an external mdb will have to provie the password. So in this instance you data is secure.

Problem is, that all users that have access to the DB use needs to enter this pwd -> could a user that knows te general pwd access columns he's not supposed to see in any way I didn't predict? I.e. I also need to protect parts of the db from certain users.

With regard to conditional formatting of columns dependant on access levels you would have to code this within the form, I suspect.

This I've allready done, and this works fine.


You have not mentioned as to whether this is a split database with a FE/BE setup. Again I suspect it is by the content of the post.

I've not split it. Should I do this? In that case - please tell me shortly why! ;)


Again you could create an MDE from the MDB and deploy that as a further means of protection.

Could you shortly comment on which things get more secure with a MDE file?

Thanks!

/henkus
 
The real question would be, exactly what do you need to protect and from *whom*?

The above sounds OK for keeping out casual workers who are otherwise honest and simply want to do their job and the database is totally internal in a company network.

OTOH, if you are concerned about some user having wanderlust and has had altered database's structure or edited directly in table or will do those, then those are not sufficient, and you will need to have a proper user-level security. This is the guide I usually recommend for learning about ULS.

HTH.

PS: I would strongly recommend that you split the database if it isn't.

PSS: MDE basically is a MDB without the source code, rendering forms and reports totally uneditable and you can't open VBA to read, let alone modify the source code for any form, report or modules. Good for protecting the database's integrity, but not so good for data integrity as tables & queries still can be read, imported, modified directly without a proper security in place.
 
I do not generally invoke Access Security. However to keep out the curious I
1) Disable By Pass Key
2) Restrict Start Up Properties
3) Custom Menu Bar giving only what is required.

All these you have done.

I do not use password because anybody who learns password can open although you have active directory determining what they can do asa safeguard. (I have no knowledge of this so cannot comment).

I do a similar thing in that I detect the network logon being used and then (1) Logon must appear in a database table else application closes and (2) I can then use this logon ID to Hide/Show command buttons thereby controlling what they can do.

Not bomb proof at all but keeps out the curious and stops the un initiated from looking/changing and code or tables etc.

Very interested in comment above relating to protecting the code by password. That is very interesting and one I will investigate for myself.

Really depends on how hard you want to keep people out. My method does not stop anybody importing all bits into new database but not everybody knows this, so depends on how clever the people are that you want to keep out

len
 
The real question would be, exactly what do you need to protect and from *whom*?

Well, basically I'm hiding parts of the table structure from part of the users. I also prefer that the DB should not be openable if copied outside of my company's network...

OTOH, if you are concerned about some user having wanderlust and has had altered database's structure or edited directly in table or will do those, then those are not sufficient, and you will need to have a proper user-level security. This is the guide I usually recommend for learning about ULS.
This was a good guideline. I've added everything in it, and also kept my own AD-security. Should make it a lot securer, thanks!

PS: I would strongly recommend that you split the database if it isn't.
Do you have a nice guideline for this too? I'm getting a lot of hits searching for split database, but most are concerning problems with it and not actually how you do it...

/henkus
 
Do you have a nice guideline for this too? I'm getting a lot of hits searching for split database, but most are concerning problems with it and not actually how you do it...

I do not have a nice guideline, but I can tell you how I do it.

I create two database one has APP in the name and the other has DATA in the name.

In your case create a new database and but DATA in the name so you know this is the database with all your tables. Once you have the table created import all your tables from the other database. Now close this database and open up your main DB.

With the main db open delete all your tables. . . . .. you can make a backup of the database prior to this if you wish, but you do have all your tables in the other database. OK once all the tables a gone go to TOOLS >> DATABASE UTILITIES >> LINK TABLE MANAGER

When prompted open the DATA database and select all the table and link them. You now have a split database.

The benifit is that you can now edit a copy of the front end and copy over the the old one. This way you do not have to get everyone out to make changes.

HTH
Rodger
 
Ok, thanks! I now have a split database, where all users log on to the front with the same username. The front has a tables as links to the backend. The front is quite nicely locked down with the start up options. However, the backend is still open to all users that have access to the front, meaning that they could in theory open the backend instead, and access tables there directly, instead of accessing the forms I want them to use.

Questions:
* Can I lock down the Backend in any way, so that normal users can't open it, or at least not access the tables directly? I've tried with the user access managenent, but when locking down rights there, I also prevented user from accessing table from form in front...

* If you don't have a good answer to question above, my plan is to first lock down everything in the backend for the normal user. Then have the front end connect to the backend with a different user that the user actually logged on with. Is this doable and recomendable? If yes/yes, do you know how to change which database everything connects to?

Thanks!

/henkus
 
I did add a password to my backend so no one could get into the back end tables. If I remember correctly I relinked them when I did this. So I set the password on the back end and then on the front end I re-linked. My front end did not have a password to get in, only the back end. Try that and see if it helps.
 

Users who are viewing this thread

Back
Top Bottom