secure backend

[Guest]

i'm using Acc97, split Fe / BE. The Fe / Be are distributed to several groups, who use the database independently. Group A will have a different copy of the Fe / Be than Group B. I also do not have access to the system.mdw files, so I don't think that user level security will work in my case. I've disable the shortcut keys on the Fe and restricted the menus, etc. However, I am at a loss on how to protect the Be. I understand that using the built in database password is almost worthless. I can put a hidden form in the Be to shut it down, but this still won't protect it from access via vba or another program (excel or word). Does any one have any suggestions? Will encrypting the database help?

thanks!
-hai

 

[Douglas J. Steele]

The only approach that will work is applying user-level security.

http://support.microsoft.com/support/access/content/secfaq.asp explains the
details.

Create a workgroup (.MDW) file for your application, and distribute it with
your application.

--
Doug Steele, Microsoft Access MVP

(No private e-mails, please)

i'm using Acc97, split Fe / BE. The Fe / Be are distributed to several

groups, who use the database independently. Group A will have a different
copy of the Fe / Be than Group B. I also do not have access to the
system.mdw files, so I don't think that user level security will work in my
case. I've disable the shortcut keys on the Fe and restricted the menus,
etc. However, I am at a loss on how to protect the Be. I understand that
using the built in database password is almost worthless. I can put a
hidden form in the Be to shut it down, but this still won't protect it from
access via vba or another program (excel or word). Does any one have any
suggestions? Will encrypting the database help?

 

[TC]

(snip)

I also do not have access to the system.mdw files,

If you have not secured your database, you >must< currently have access to
the system.mdw file; otherwise, Access would refuse to run.

HTH,
TC

 

[Jack MacDonald]

With userlevel security, if you place the MDW file in the same network
location as the BE, then the users will clearly have access to the MDW
file. Therefore, implement userlevel security with groups defined in
that single, shared MDW file. If you have distributed users in remote
locations, then you can copy the MDW to their computer or server.
Define all your permissions using groups, rather than individual
users, to minimize the maintenance issues with the remote MDW files.

Additional information in the document on the website in my signature.

i'm using Acc97, split Fe / BE. The Fe / Be are distributed to several groups, who use the database independently. Group A will have a different copy of the Fe / Be than Group B. I also do not have access to the system.mdw files, so I don't think that user level security will work in my case. I've disable the shortcut keys on the Fe and restricted the menus, etc. However, I am at a loss on how to protect the Be. I understand that using the built in database password is almost worthless. I can put a hidden form in the Be to shut it down, but this still won't protect it from access via vba or another program (excel or word). Does any one have any suggestions? Will encrypting the database help?

thanks!
-hai

=======================================================
Jack MacDonald
remove UPPERCASE LETTERS from email address
Vancouver, B.C. Canada
Info about MSAccess user-level security
www.geocities.com/jacksonmacd

 

[TC]

I agree that the normal security screens are fairly confusing. A person who
was not knowledgable about Access security, would not be able to use them
properly, in my opinion.

A different approach is to write your own security screens. These could be
designed to be simpler, or they could be customized specifcally for your
application. However, writing such screens needs a fairly high level of
underdstanding, on your part, of the details of Access security.

The best thing would be for you to tell us what the DBAs need to be able to
do, from a functional viewpoint. What things must they allow, or deny, or
change, on the end-user databases?

Hai, one more thing: when you reply to a post, please include the text of
the post that you are replying to: just like I have done below. Often, a
post will disappear from the reder's news server. So if you don't include
the text of the post that you are replying to, the reader will not know what
you're talking about - and he will not have time to go back through his
archives, to find it.

Cheers,
TC
(off for the day)

Thank you all for your input. Let me clarify a bit. The database will be

distributed to other "dba's" who will then administer the database. These
"dba's" are very unfamiliar with Access and will be completely dependent on
the custom user interface that I've built for them. I won't be able to
administer security for them as I won't have access to THEIR .mdw file. I
am also hesitant to have them administer it as this is the first time
they've used Access... I find setting up the security confusing (I've been
programming in Access vba for several years) so I assume that proper
administration may be beyond a newbie...but I could be totally off-base.
Anyone have any thoughts?

 

[Guest]

Thank you all for your input. Let me clarify a bit. The database will be distributed to other "dba's" who will then administer the database. These "dba's" are very unfamiliar with Access and will be completely dependent on the custom user interface that I've built for them. I won't be able to administer security for them as I won't have access to THEIR .mdw file. I am also hesitant to have them administer it as this is the first time they've used Access... I find setting up the security confusing (I've been programming in Access vba for several years) so I assume that proper administration may be beyond a newbie...but I could be totally off-base. Anyone have any thoughts

Thanks
-hai

 

[Guest]

Here are the requirements
Front end: restrict access to specific forms and reports based on user - I've already done this with custom menus, log on, and by disabling the bypass keys and special key

Back end: prevent access by anyone or any program, except the front end. The only way to access the back end is via the front end. Also, I'll need to leave a door for myself, in case they screwed up the back end - so that I can go in and fix it
I can encrypt the backend (using the built in function) and password protect it - to provide light protection against casual tampering. However, I would like something a bit more robust. What ever I do, it must be very easy to administer as some of the "dba's" are not very computer literate. Unfortunately, I really don't understand the built in security..

I have seen a database where the database was unprotected, but the data was encrypted and incomprehensible. This may be an option, but I'm not sure how to do this

thanks for the input
-ha

----- TC wrote: ----

I agree that the normal security screens are fairly confusing. A person wh
was not knowledgable about Access security, would not be able to use the
properly, in my opinion

A different approach is to write your own security screens. These could b
designed to be simpler, or they could be customized specifcally for you
application. However, writing such screens needs a fairly high level o
underdstanding, on your part, of the details of Access security

The best thing would be for you to tell us what the DBAs need to be able t
do, from a functional viewpoint. What things must they allow, or deny, o
change, on the end-user databases

Hai, one more thing: when you reply to a post, please include the text o
the post that you are replying to: just like I have done below. Often,
post will disappear from the reder's news server. So if you don't includ
the text of the post that you are replying to, the reader will not know wha
you're talking about - and he will not have time to go back through hi
archives, to find it

Cheers
T
(off for the day

Thank you all for your input. Let me clarify a bit. The database will b

distributed to other "dba's" who will then administer the database. Thes
"dba's" are very unfamiliar with Access and will be completely dependent o
the custom user interface that I've built for them. I won't be able t
administer security for them as I won't have access to THEIR .mdw file.
am also hesitant to have them administer it as this is the first tim
they've used Access... I find setting up the security confusing (I've bee
programming in Access vba for several years) so I assume that prope
administration may be beyond a newbie...but I could be totally off-base
Anyone have any thoughts

 

[TC]

Here are the requirements:
Front end: restrict access to specific forms and reports based on user -

I've already done this with custom menus, log on, and by disabling the
bypass keys and special keys

Back end: prevent access by anyone or any program, except the front end.

The only way to access the back end is via the front end.

To do this, you will need to ensure that >all< access to the back-end
tables, from the front-end prograns is via so-called Run With Owner
Permission (RWOP) queries. That is the only way you will be able to meet
that aim. And to do it, you will have to develop a faiurly good level of
understanding of Access security. I just do not see any way around that.
Otherwise, anyone who has Access can create a new db, and link to the tables
in your back-end db, thus being able to access their data, without >running<
the back-end db.

Also, I'll need to leave a door for myself, in case they screwed up the

back end - so that I can go in and fix it.

You would do this by having a special workgroup file which gave you the
necessary levels of (extra) access. You would not need any "back door" apart
from that.

I can encrypt the backend (using the built in function) and password

protect it - to provide light protection against casual tampering.

The built in encryption is no help to you here. Anyone with Access can read
an unsecured "encrypted" database. Putting a database password on the back
end would be fair. They are easy to crack using code that is freely
available all over the web - but as they say, "a small effort keeps 99% of
people out; no amount of extra effort will keep the other 1% out".

However, I would like something a bit more robust. What ever I do, it

must be very easy to administer as some of the "dba's" are not very computer
literate.

You have still not said what the DBAs must be able to >do<. What must they
be able to do?

Unfortunately, I really don't understand the built in security...

You'll have to make the effort to learn it, unless you design your own
custom scheme.

I have seen a database where the database was unprotected, but the data

was encrypted and incomprehensible. This may be an option, but I'm not sure
how to do this.

Certainly that would be possible - but also require lots of coding effort,
and some crypto expertise. Is the value of your data, really worth it?

HTH,
TC