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

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



"Pecanfan" <pecanfan@xxxxxxx> wrote in message
news:1130350451.111889@xxxxxxxxxxxxxxxxxxxxx
> 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
>
>


.

Relevant Pages

  • User Level Security with a Front-End/Back-End Solution
    ... function to refresh the links to the back-end database. ... Permissions for the linked tables in the front-end was set to read, update, ... database the name is the same but the security is in a .mdw file I don't ...
    (microsoft.public.access.devtoolkits)
  • Re: Access SQL Server Express over the Internet
    ... You have the security end probably covered, but I find it difficult to believe that you don't have performance problems, unless you don't query that database very often. ... decoupling of the front end and back-end. ... You can change one end without having to change the other end => less deployment problems when upgrading ...
    (borland.public.delphi.database.ado)
  • Re: Appending a field to a table -AND- accessing a split back-end
    ... What I prefer to do is to create a separate "updater" mdb to perform the ... I am assuming the goal here is to update a back end database to a later ... > back-end by adding tables and querries progamatically. ... > tblTable as it's record source and add fldField to it and place a command ...
    (microsoft.public.access.modulesdaovba)
  • Re: Need technique to programatically update back end structure / relationships
    ... and verify they have the right database by using the same ... If you are comfortable programming in another language, ... > install, the user selects whether this is a full install (in which case an ... > case the back-end database is left alone and eveything else is replaced). ...
    (microsoft.public.access.tablesdbdesign)
  • Re: splitting the database and securing the back-end file?
    ... Setting a database password is NOT user-level security. ... Graham Mandeno ... what goes in the back-end, ...
    (microsoft.public.access.security)
Quantcast