security on back end mdb

[Guest]

I split the main mdb into a back end mdb and an mde file. The mde file is on each workstation and contains
the queries, forms, reports, macros and modules. The file is password protected, all special keys have been disabled, the
shift key has been disabled, so should be secure at the front end.
all queries have read with owner permission. the mde file is linked to the back end mdb file.
how do i protect the back end mdb?

if someone, other than this group of users, gets to the server, one can easily open the tables and export
the data.

 

[Rick Brandt]

I split the main mdb into a back end mdb and an mde file. The mde file is

on each workstation and contains

the queries, forms, reports, macros and modules. The file is password

protected, all special keys have been disabled, the

shift key has been disabled, so should be secure at the front end.
all queries have read with owner permission. the mde file is linked to the back end mdb file.
how do i protect the back end mdb?

if someone, other than this group of users, gets to the server, one can

easily open the tables and export

the data.

The only way to protect JET data is to use Access User-Level Security.
While hackable, it is the best you can do to protect JET tables. Otherwise
you need to move your data to a server-based engine that has good security.

 

[Guest]

terribly sorry to be so dense, but if i have a standalone mdb on a server that only has tables, i do not see
how creating an mdw at that level does the trick

i have it at the mde level and there is the linkage from the mde to the mdb. that 'secures' the actua
users. the server is secure via the organization's standards.
since i am a contractor developing the app, i am working with the organizations it department
and they want to make sure everything is tight at the server end. personally, i feel a hacker getting
to the server is remote, since the organization has all the necessary security for the server. i thin
the dept is taking the hipaa requirements to most detailed level

 

[Tim Ferguson]

how creating an mdw at that level does the trick.

Try reading: the help files or books on Access will both explain the
Security system. There are white papers on the Microsoft knowlege base on
using access security -- and it is worth studying these closely, and
practising a bit first, because it is possible to (a) lock yourself out of
your own data and (b) leave big loopholes. Done properly, though, it is a
pretty secure system that will keep out all but the most determined
crackers.

HTH


Tim F

 

[Rick Brandt]

terribly sorry to be so dense, but if i have a standalone mdb on a server

that only has tables, i do not see

how creating an mdw at that level does the trick.

i have it at the mde level and there is the linkage from the mde to the mdb. that 'secures' the actual
users. the server is secure via the organization's standards.
since i am a contractor developing the app, i am working with the organizations it department
and they want to make sure everything is tight at the server end.

personally, i feel a hacker getting

to the server is remote, since the organization has all the necessary

security for the server. i think

the dept is taking the hipaa requirements to most detailed level.

For users to be able to use the data from the front end file they need full
permissions to the folder where the data file resides. That means there is
no file-level security that can prevent them from accessing the file
directly and/or linking to it and/or importing it.

User-Level security will give you *some" measure of security in that regard
assuming that no one who wants to break in knows about and is willing to
obtain the tools/knowledge to break that.

The bottom line is that data that "really needs" to be secured, doesn't
belong in an MDB file.