Home All Groups Group Topic Archive Search About
Author
19 Sep 2007 10:06 PM
K Anderson
I have a database that will be stored on a network where folks from around
the country will do essentially data entry. They need to be able to add new
records, update existing ones, and run reports. They must not be allowed to
edit data directly in the tables, or they will screw up each other's records.
I have implemented the security measures described below, and I am looking
for any input regarding security loopholes I may need to go back and cover. I
am using Access 2003, btw.

User-level security is defined, and the workgroup information file is kept
on my hard drive, many many miles from each of the users I am guarding
against. The users group (including the default Admin user) has read and
update permissions on the tables, in order for the forms to work. But I don't
want them going into the tables directly. I've seen the recommended procedure
here is to block permissions on the tables and then run the form on an RWOP
query, but I don't really understand the point since they can then just go
directly into the query (instead of the table) and edit the data there still
without using the forms. Anyway, I've implemented a switchboard startup form
for them to use, disabled the database window so they can't find the tables,
disabled the F11 key and the shift-bypass key, created a custom file menu,
and disallowed toolbar/menu changes so they can't cheat and bring up the
database window anyway, and password-protected the vb so they can't do
anything sneaky in that way. Still, though, I feel like there's probably a
really easy way one could bypass all of this in five seconds. I just want
other people with more experience than I to take a look at what I've done so
far and let me know of anything stupid I missed.

Thanks in advance for any help.


--K

Author
20 Sep 2007 9:23 AM
Keith Wilby
"K Anderson" <K Ander***@discussions.microsoft.com> wrote in message
news:7F8F7962-AC01-4282-9FD1-BBF1361A46CC@microsoft.com...
>
> User-level security is defined, and the workgroup information file is kept
> on my hard drive, many many miles from each of the users I am guarding
> against.

How do you expect the users to get in at all if the WIF isn't available to
them?

Show quote
> The users group (including the default Admin user) has read and
> update permissions on the tables, in order for the forms to work. But I
> don't
> want them going into the tables directly. I've seen the recommended
> procedure
> here is to block permissions on the tables and then run the form on an
> RWOP
> query, but I don't really understand the point since they can then just go
> directly into the query (instead of the table) and edit the data there
> still
> without using the forms.  Anyway, I've implemented a switchboard startup
> form
> for them to use, disabled the database window so they can't find the
> tables,
> disabled the F11 key and the shift-bypass key, created a custom file menu,
> and disallowed toolbar/menu changes so they can't cheat and bring up the
> database window anyway, and password-protected the vb so they can't do
> anything sneaky in that way. Still, though, I feel like there's probably a
> really easy way one could bypass all of this in five seconds. I just want
> other people with more experience than I to take a look at what I've done
> so
> far and let me know of anything stupid I missed.
>

If you've done all of that then they can't get to your queries anyway.  The
only other method of protection you haven't mentioned is providing users
with an mde file.  Have you tested your security thoroughly?  It's easy to
miss a step and leave a back door open.  Try getting users to link to your
BE file for example (they shouldn't be able to).

Regards,
Keith.
www.keithwilby.com
Author
20 Sep 2007 1:58 PM
AccessHelp
What I do on my databases is I disable/uncheck all the options on the
"Startup" window, except the option "Allow Built-in Toolbars" (unless you
have your own built-in toolbars).  Then I hide all the objects (tables,
queries, etc.), and I uncheck the option "Hidden objects" in the View tab of
Options window (Tools|Options).  That way even they can get into the database
window (thru report windows), they won't see or have access to the objects. 
That is done on the FE database. 

For the BE database, I place it in a remote area in the network.  Also on
the FE, I have a button to compact the BE database so that I won't have to
compact it. 

If anyone has a better way of doing, please feel free to share. 



Show quote
"K Anderson" wrote:

> I have a database that will be stored on a network where folks from around
> the country will do essentially data entry. They need to be able to add new
> records, update existing ones, and run reports. They must not be allowed to
> edit data directly in the tables, or they will screw up each other's records.
> I have implemented the security measures described below, and I am looking
> for any input regarding security loopholes I may need to go back and cover. I
> am using Access 2003, btw.
>
> User-level security is defined, and the workgroup information file is kept
> on my hard drive, many many miles from each of the users I am guarding
> against. The users group (including the default Admin user) has read and
> update permissions on the tables, in order for the forms to work. But I don't
> want them going into the tables directly. I've seen the recommended procedure
> here is to block permissions on the tables and then run the form on an RWOP
> query, but I don't really understand the point since they can then just go
> directly into the query (instead of the table) and edit the data there still
> without using the forms. Anyway, I've implemented a switchboard startup form
> for them to use, disabled the database window so they can't find the tables,
> disabled the F11 key and the shift-bypass key, created a custom file menu,
> and disallowed toolbar/menu changes so they can't cheat and bring up the
> database window anyway, and password-protected the vb so they can't do
> anything sneaky in that way. Still, though, I feel like there's probably a
> really easy way one could bypass all of this in five seconds. I just want
> other people with more experience than I to take a look at what I've done so
> far and let me know of anything stupid I missed.
>
> Thanks in advance for any help.
>
>
> --K
Author
20 Sep 2007 9:09 PM
Joan Wild
"AccessHelp" <AccessH***@discussions.microsoft.com> wrote in message news:962EE4D9-B211-42EF-87B2-B5AC9328E2F1@microsoft.com...
> What I do on my databases is I disable/uncheck all the options on the
> "Startup" window, except the option "Allow Built-in Toolbars" (unless you
> have your own built-in toolbars).  Then I hide all the objects (tables,
> queries, etc.), and I uncheck the option "Hidden objects" in the View tab of
> Options window (Tools|Options).  That way even they can get into the database
> window (thru report windows), they won't see or have access to the objects. 
> That is done on the FE database. 

Just an FYI, but that setting only applies to your installation of Access.  It doesn't travel with the mdb file - not that it matters in your case since users don't have the Tools menu.  Just thought I'd point it out.

> For the BE database, I place it in a remote area in the network.  Also on
> the FE, I have a button to compact the BE database so that I won't have to
> compact it. 

You can actually put the BE mdb in a hidden folder
\\servername\share$ will hide it.

AddThis Social Bookmark Button