Security and .mdE

  • Thread starter Thread starter Dave
  • Start date Start date
D

Dave

I am just getting into the whole thing of splitting my DB and creating an
..mdE and the thought occured to me that it may cause a security issue.
I have never used Access Security but here is My question(s).

1. In a low risk envirnoment IS additional security neccessary if I have the
back end on the server and the front end (properly - shutting off access to
tools and the like) on workstations?

2. IF additional security is reccommended (in this or any other project) how
do I corredinate that with splitting the DB?
- so if I split the DB can I add securtiy to both the fe and the be?
OR if I add security before splitting does one of the pieces lose its
security?

and any other issues I should be awair of before I go down this path?

Any help here will be appreciated.

Thanks in advance
D
 
Dave said:
I am just getting into the whole thing of splitting my DB and creating an
.mdE and the thought occured to me that it may cause a security issue.
I have never used Access Security but here is My question(s).

1. In a low risk envirnoment IS additional security neccessary if I have the
back end on the server and the front end (properly - shutting off access to
tools and the like) on workstations?
Click to expand...

If you lock down the frontend, that is often sufficient to keep users out of mischief. It depends on how savvy or determined your users are. Even with security, the determined can hack their way in.
Be sure to create custom menus/toolbars for use throughout your application; create a startup form (a main menu form if you have one) that is opened on startup.
Use the features in Tools, Startup to
set the startup form
set your default menu (the custom one you made)
disable all the checkboxes about allowing built in menus, toolbars, changes etc.
hide the db window (ensure the custom menu you create does not include the Windows, Unhide item)
disallow special keys (this will disable the F11 key, among others)

If you need to bypass these startup features, you can hold the shift key down while you open the db. If you feel that your users may use this to bypass your settings, you can disable the shift key bypass - there's an example in help for doing this(look for AllowBypassKey) or at
http://www.mvps.org/access/modules/mdl0011.htm
and
http://www.mvps.org/access/general/gen0040.htm

You can also create a MDE from your database, which will prevent changes to forms, reports and modules (If you do this, be certain to keep your original mdb in case you need to make changes).
2. IF additional security is reccommended (in this or any other project) how
do I corredinate that with splitting the DB?
- so if I split the DB can I add securtiy to both the fe and the be?
Click to expand...

If you do implement security, you'd secure both the FE and BE using the same workgroup file. Be sure to follow a set of steps to ensure you implement security properly. See www.jmwild.com/AccessSecurity.htm
OR if I add security before splitting does one of the pieces lose its
security?
Click to expand...

Don't use the splitter wizard on a secure database as that will remove the security on the BE, but leave the FE secure. Instead, split it manually. See www.jmwild.com/SplitSecure.htm
 
Here's my opinion <g>

Splitting and changing to mde are quite separate things. Both are recommended.

Splitting is for speed, and it is claimed for reliability. MDE is to prevent
your code being looked at (and that's all)

I note that Oracle has "gone off" the Client/Server model since 1995. Although
Access FE/BE splitting is only a poor cousin of true Client/Server, it
nevertheless attempts to simulate the same thing. (ref: "SOFTWAR, Larry
Ellison and Oracle", Matthew Symonds, Simon & Schuster). Nevertheless, and
apart from a web-based model which I believe Access can support, Access is
best served by "splitting".

Access Security is only usefull in a "low-risk" environment. That said, it is
nevertheless usefull because "most environments" are, arguably, "low-risk". It
stops lesser than "experts" or "determined entities" getting into it!

It is your call whether additional security is worthwhile. For a single
single-user site, I don't bother. Otherwise I implement full Access Security,
because it's the best you can do with Access.

The way I implement Access User Level Security, which may or may not be the
best way but it's certainly simple, is that I write my program/database as a
single file, implement security, then take a copy of the hopefully finished
database. One copy becomes the Back-End by removing everything EXCEPT Tables
(and Relationships if set). The other copy becomes the Front-End by removing
the Tables (replacing them with links) AND Relationships if set. Although
Relationships can remain with linked tables, they do nothing in that case.

Voila! Fully ULS secured, and I only had to do it once! I am not sure, because
I don't use it, of the steps required to use the "Security Wizard". Every
"copy" of an mdb/mde carries ULS with it.

It is said, with good reason, that ULS Security is "difficult to implement".
Certainly, one needs to follow the SECFAQ document here:
http://support.microsoft.com/default.aspx?scid=/support/access/content%2
Fsecfaq.asp

I think Access ULS security is worthwhile, because it's generally the best you
can do with Access! However, if you are developing something anew, be aware
that Access2007 has dropped the secirity model (except for legacy-mode). I
don't know what you are supposed to do with A2007!

Chris
 
Back
Top