Access security best practice - Stupid question(s) #2

[Pecanfan]

OK, just about got my nice new secure access database up and running and so
far so good. All I want to check now is that I'm doing things as per best
practices. I've ready through the various security FAQ and I think this
covers it...

- My back-end database is secured through a shared .mdw file
- My back-end database is also secured with a database password
- My back-end database is encoded
- My front-end is secured through the same shared .mdw file (no database
password and not encoded)
- Security on the linked tables in the front end is quite open (everyone can
Read Design, Read Data, Update Data, Insert Data, Delete Data)
- Security on the back end actual tables is locked down to my various
groups, as appropriate
- Admin user has no rights to anything and instead I have a separate dbadmin
account which is the only account in the 'Admins' group
- The 'Users' group has no rights to anything and instead I have separate
groups for each department etc.
- Everyone has full (well, Modify) NTFS permissions to my hidden (for what
it's worth) back-end .mdb file and .mdw file

Until I get time to sort out RWOP would you say the above is about right in
terms of best practice, if there is such a thing? Have I missed something?

ONCE I sort out RWOP, I gather I just remove all 'user' group permissions
from the tables in the back end and from the linked tables in the front end
then just control permissions on the actual queries?

Thanks again!

Andy

 

[Lynn Trapp]

Looks pretty good to me, Andy. I'm not sure why you chose to put a database
password on your back-end, but there probably isn't any harm in it -- as
long as someone there always knows what that password is.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Access Junkie List:
http://home.bendbroadband.com/conradsystems/accessjunkie.html

 

[Jeff Conrad]

Looks pretty good to me Andy.

Just to check, who is the Owner of the database objects and the database itself?
(Both FE and BE)

To check yourself, try and log into the database using the default system workgroup
file. If you can get in, then you missed a step or two. It does not look like you
missed anything, but a quick check is always a good thing.

You might also consider disabling the shift key bypass as well.

--
Jeff Conrad
Access Junkie - MVP
http://home.bendbroadband.com/conradsystems/accessjunkie.html
http://www.access.qbuilt.com/html/articles.html

in message:

 

[Joan Wild]

- My back-end database is secured through a shared .mdw file
- My back-end database is also secured with a database password
- My back-end database is encoded

What does that mean?

- My front-end is secured through the same shared .mdw file (no
database password and not encoded)

You might consider creating a MDE to distribute to users and keep the MDB
for changes you make.

ONCE I sort out RWOP, I gather I just remove all 'user' group
permissions from the tables in the back end and from the linked
tables in the front end then just control permissions on the actual
queries?

Yes, but not necessary to remove permissions from the links.

 

[TC]

Understand that setting up an RWOP query is more than just adding "WITH
OWNERACCESS OPTION" to the end of it. You have to carefully determine
who the /owner/ of the query is. RWOP queries are executed with the
permissions of the /owner/ of that query - not with the permissions of
the user who is /running/ the query.

HTH,
TC

 

[Pecanfan]

Looks pretty good to me Andy.

Just to check, who is the Owner of the database objects and the database itself?
(Both FE and BE)

The owner of everything is the dbadmin user, which only gets used for
changes. I'm assuming this is the proper way of doing things. I didn't use
the wizard for setting up the security - did it manually since I hate not
knowing what other stuff wizards are doing without my knowledge.

You might also consider disabling the shift key bypass as well.

I considered this but then I'd need two front ends - one used for
development and then a final 'locked down' one. Which is fine, but at the
moment I've got so many changes to make and so few staff to break it I'm
running the risk of sticking to a single front end for the moment. Even if
they manage to bring up the database window I don't think they'll be able to
do much damage (he says!).

Cheers all,

Andy

 

[Keith]

I considered this but then I'd need two front ends - one used for
development and then a final 'locked down' one.

No you wouldn't. You would enable the bypass key for development and
disable it before copying it into the production environment.

Keith.
www.keithwilby.com

 

[Jeff Conrad]

in message:

Hi Andy, comments in-line....

The owner of everything is the dbadmin user, which only gets used for
changes. I'm assuming this is the proper way of doing things.

There are some occasions when this is not needed, but for what you
are trying to do, yes, you did it correctly.

I didn't use the wizard for setting up the security - did it manually since I hate not
knowing what other stuff wizards are doing without my knowledge.

Perfect.
Although the security wizard is a helpful tool, it takes away the knowledge of
what is happening behind the scenes.

I considered this but then I'd need two front ends - one used for
development and then a final 'locked down' one. Which is fine, but at the
moment I've got so many changes to make and so few staff to break it I'm
running the risk of sticking to a single front end for the moment. Even if
they manage to bring up the database window I don't think they'll be able to
do much damage (he says!).

It was only a suggestion, but when you distribute the FE to your users I
still think it would be a good idea. Most likely your users will not even
know you did this as it will be a transparent change.