Securing a split database without user level security

[Andy]

Hi !
I split a simple Access2K database ( shared on network )and placed
the files thusly :

x:\app\frontend .mdb

x:\app\back\bac kend.mdb

Problem :
I once read an article that laid out a "permission " scheme that ,
while not perfect, was effective at providing some protection ( from
outright deletion for example ). This scheme had one assign certain
permissions to the mdb's and other permissions for the folders where
they reside.

Can anyone help on this issue ?
I am not able to locate the original article nor recall it's details.

André in Montréal

[Davis]

Re: Securing a split database without user level security

sosandre@hotmai l.com (Andy) wrote in message news:<50cf9e6a. 0405180939.47d1 47eb@posting.go ogle.com>...[color=blue]
> Hi !
> I split a simple Access2K database ( shared on network )and placed
> the files thusly :
>
> x:\app\frontend .mdb
>
> x:\app\back\bac kend.mdb
>
> Problem :
> I once read an article that laid out a "permission " scheme that ,
> while not perfect, was effective at providing some protection ( from
> outright deletion for example ). This scheme had one assign certain
> permissions to the mdb's and other permissions for the folders where
> they reside.
>
> Can anyone help on this issue ?
> I am not able to locate the original article nor recall it's details.
>
> André in Montréal[/color]


Why don't you want to implement User-level security? It's not that
hard and is very effective.

[Bradley]

Re: Securing a split database without user level security

Andy wrote:[color=blue]
> Hi !
> I split a simple Access2K database ( shared on network )and placed
> the files thusly :
>
> x:\app\frontend .mdb
>
> x:\app\back\bac kend.mdb
>
> Problem :
> I once read an article that laid out a "permission " scheme that ,
> while not perfect, was effective at providing some protection ( from
> outright deletion for example ). This scheme had one assign certain
> permissions to the mdb's and other permissions for the folders where
> they reside.
>
> Can anyone help on this issue ?
> I am not able to locate the original article nor recall it's details.
>
> André in Montréal[/color]

I take it you are talking about fiel system permissions?

Access required Read/Write permissions on the databases and
Read/Write/Create permissions for new files in the folder (to create the
LDB locking file).

I think that is it.... ?
--
regards,

Bradley

[Rob]

Re: Securing a split database without user level security

I've got to plug a book by Garry Robinson, "Real World MS Access
Database Protection and Security." A great resource if you want to
protect your database. Highly recommended.
Rob

[Bradley]

Re: Securing a split database without user level security

Rob wrote:[color=blue]
> I've got to plug a book by Garry Robinson, "Real World MS Access
> Database Protection and Security." A great resource if you want to
> protect your database. Highly recommended.
> Rob[/color]

Can it stop an Access database being hacked? I can get past almost any
workgroup (with or without a workgroup file), database password and
encryption security.

I think the only way to secure a database properly is by starting off
removing access to the database file and use a "service" like
MSSQL/others use. Until you have physical security of the database file
you are fighting a lossing battle I reckon. :)

Thanks for the book idea, I might try and find a copy.
--
regards,

Bradley

[Rob]

Re: Securing a split database without user level security

No question, removing access to the files is the best way. However,
there are a number of things that can be done to make it 'difficult'
if not impossible that most people wouldn't think of or know to try.
Check out the book. Its definitely the most authoritative book I've
seen on the topic.
Rob

[Bradley]

Re: Securing a split database without user level security

Rob wrote:[color=blue]
> No question, removing access to the files is the best way. However,
> there are a number of things that can be done to make it 'difficult'
> if not impossible that most people wouldn't think of or know to try.
> Check out the book. Its definitely the most authoritative book I've
> seen on the topic.
> Rob[/color]

I shall.

I agree...
eg.
Rename the database from .mdb to something else
Startup procedure or Autoexec macro in backend to shutdown database if
opened
etc.

:)
--
regards,

Bradley

[Garry Robinson - Editor www.vb123.com]

Re: Securing a split database without user level security

The best way to protect the file from being deleted is

A) Back up the file often
B) Protect the file using Windows Security. This should be applied to
the folder that the database resides in. You can firstly setup
permissions in windows so that only accounts that you specify can use
the database rather than every account in your domain.

You can find an article on this at my web site vb123.com

http://www.vb123.com/toolshed/04_docs/accessdb_op_security.htm

Once you have that up and running, you can make it very difficult for
an ordinary user to browse the database folder. This makes it very
difficult to delete the backend as you can make them really struggle
to find out the name of the file. I detail this in my book. Thanks
for the kind words above.

C) You can also maintain a connection/open to the database thereby
stopping anyone from deleting the file as it will be in use. Haven't
ever done anything on that but it shouldn't be too hard to do.

Renaming the database to an unknown filetype may hinder your backups
and administrators from finding the database and backing it and
recovering it as they will miss it in the searches.

On a different topic, have a say about what you want in Access 2006 at
vb123.blogspot. com

I have stated my points of view.

"Bradley" <bradley@REMOVE THIScomcen.com. au> wrote in message news:<HAtsc.777 9$L.1585@news-server.bigpond. net.au>...[color=blue]
> Rob wrote:[color=green]
> > No question, removing access to the files is the best way. However,
> > there are a number of things that can be done to make it 'difficult'
> > if not impossible that most people wouldn't think of or know to try.
> > Check out the book. Its definitely the most authoritative book I've
> > seen on the topic.
> > Rob[/color]
>
> I shall.
>
> I agree...
> eg.
> Rename the database from .mdb to something else
> Startup procedure or Autoexec macro in backend to shutdown database if
> opened
> etc.
>
> :)[/color]