|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Access to Tablesthe 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 "K Anderson" <K Ander***@discussions.microsoft.com> wrote in message How do you expect the users to get in at all if the WIF isn't available to 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. them? Show quote > The users group (including the default Admin user) has read and If you've done all of that then they can't get to your queries anyway. The > 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. > 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 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 "AccessHelp" <AccessH***@discussions.microsoft.com> wrote in message news:962EE4D9-B211-42EF-87B2-B5AC9328E2F1@microsoft.com... 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.> 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 You can actually put the BE mdb in a hidden folder> the FE, I have a button to compact the BE database so that I won't have to > compact it. \\servername\share$ will hide it. |
|||||||||||||||||||||||