Database security on a Local Network

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

This is regarding general protection of a database hosted on a network. I am
developing a database application for my college library using VB.NET, that
will reside on a network.
For some reasons, I did not want to hardcode the Database location in the
application. Instead, when a user logs in, he can choose the database
location using a folder browser control, if the location has changed.

Now, I realize that for this, I have to put the database in a shared folder,
which makes it quite vulnerable. Having pondered over the problem for
sometime, a solution that comes to my mind is to place a Text file in the
same shared folder that always contains the correct path of the database.
When a user chooses that folder, I will read the actual path of the database
from the text file, and move the database to a non-shared folder.
I haven't yet implemented this approach, but felt it better to consult
someone before. So, would this approach work, and is it a good idea.
 
Rahul said:
This is regarding general protection of a database hosted on a
network. I am developing a database application for my college
library using VB.NET, that will reside on a network.
For some reasons, I did not want to hardcode the Database location in
the application. Instead, when a user logs in, he can choose the
database location using a folder browser control, if the location has
changed.

Now, I realize that for this, I have to put the database in a shared
folder, which makes it quite vulnerable. Having pondered over the
problem for sometime, a solution that comes to my mind is to place a
Text file in the same shared folder that always contains the correct
path of the database. When a user chooses that folder, I will read
the actual path of the database from the text file, and move the
database to a non-shared folder.
I haven't yet implemented this approach, but felt it better to consult
someone before. So, would this approach work, and is it a good idea.
Click to expand...

I think you worded that incorrectly. Do you mean you want to store the data
file in a non-shared folder until a user does this and THEN move it to a shared
folder? If you move it to a non-shared folder then the user will not have
access to it.

If the database moves how will the user know this and where it was moved to?

If you want to provide some protection the opposite approach is normally used.
That is, the file is placed in a folder that is shared, but hidden and only the
admins know what the hidden share is. That way users have *access* to the file
via your app, but would have a hard time doing anything to the file outside your
app because they won't know where it is.
 
Rahul said:
I think I worded that incorrectly... What I want to say is that the
database will always remain in a non-shared folder on the server. But
there will be a shared folder that will contain a text file, which
will always contain the correct path of the DB on the server.
So, when a user logs in, he will select the path of the text file. As
he will do so with a folder chooser, he will not know that the folder
contains a text file & not the actual DB. Internally, I will read the
database path from that file in my application, & use that path to
construct the connection string...

I hope I am clear now... The reason I dont want the DB to be in a
shared folder on the server is that if I put it in a shared folder,
someone might try to access it through the Explorer directly...
Click to expand...

But if I am running your application and the DB is in a folder that I do not
have share rights to then your app will not work. Putting it in a folder that
is shared, but hidden, is the way to keep people from poking around in explorer
and opening it.
 
Rahul said:
I haven't tried it yet, but I thought that my request for data will
go to the Access Engine on the server, & not directly to the
database. As the engine on the server will obviously have access to
the database, passing its path in the connection string will still
make it process the application's request???
So, am I wrong in my point????
Click to expand...

Not unless you are usign a very unorthodox method. Access/Jet is a file serving
database. All processing is local. The server is just a hard drive on the end
of long wire.
The Jet DLLs need to be local (as far as I know).

A Terminal Server setup would work similar to what you are describing.
 
Not unless you are usign a very unorthodox method. Access/Jet is a file serving
database. All processing is local. The server is just a hard drive on the end
of long wire.
The Jet DLLs need to be local (as far as I know).

A Terminal Server setup would work similar to what you are describing.
Click to expand...

In principle, I agree with you, but how's this for unorthodox??

Create an MDB (#1) on a non-shared folder on the server.
Create another MDB (#2) in a shared location on the same server.
Link all the tables in #1 to #2 so they are accessible to #2

Create a public function in #2 that accepts SQL strings as parameters
and runs those SQL statements against its linked tables. The function
returns a DAO recordset. A single, general purpose function is
sufficient to service all the Select queries to be run against the
linked tables. A second public function for processing Action queries
could also be created.

At this point, you could (for testing purposes) write a procedure in
#2 that would create a DAO recordset object variable, and use an SQL
string to populate the recordset object variable with a recordset from
#1.So far, so good (if somewhat convoluted!)

Then create MDB #3 on a workstation.
Create a reference from #3 to #2, thus making all the public
functions, including the SQL-processing functions, in #2 visible to
#3.

Copy the testing procedure from #2 into #3. It runs exactly the same,
thus demonstrating that a table from a MDB file in a non-shareable
folder on the server is accessible to the network.

Of course, #2 is subject to accidental deletion, just as is a
conventional shared MDB file. However, the valuable data is hidden
from accidental deletion. It's almost as if Jet could become the
server in a client-server architecture.

Practical...?? No.
Interesting...?? Perhaps.
Have I ever implemented it...?? Only as far as to prove it was
technically feasible in Access 97. Dunno about later versions, but I
imagine it works the same.

One interesting and unexpected side effect of this bizarre method is
that queries run an order of magnitude faster than they would
otherwise. Shouldn't happen, but I've seen it and timed it.
 
Practical...?? No.
Interesting...?? Perhaps.
Have I ever implemented it...?? Only as far as to prove it was
technically feasible in Access 97. Dunno about later versions, but
I imagine it works the same.

One interesting and unexpected side effect of this bizarre method
is that queries run an order of magnitude faster than they would
otherwise. Shouldn't happen, but I've seen it and timed it.
Click to expand...

Would you be able to put together a very simple demo of this, with
the two server-side MDBs?

It really is a pretty fascinating idea.
 
Would you be able to put together a very simple demo of this, with
the two server-side MDBs?

It really is a pretty fascinating idea.
Click to expand...


Yeah, I can dredge out some old stuff that I did. It must be about 5
years ago now that I was playing around with this idea.

I had originally been intrigued because of the speed improvement, not
the "hiding" aspect. However, I misspoke about the configuration that
gave the speed improvement -- what I had tested originally was when
the public function and the tables were both in a single MDB file. So
I don't know whether the speed improvement will be present in the
three-MDB scenario that I described, but it definitely was present in
a two-MDB scenario. My hunch is there is something fundamentally
different in how Jet deals with linked or local tables.

Anyway, I will try to find it within the next few days and email it to
you.

One of the reasons that I never persued it in any real application is
that it eliminates the possibility of using bound forms. I am addicted
to the ease of use of bound forms, and have never developed a protocol
for using unbound forms based on recordsets.

There was a paper floating around within the last few weeks, written
by Alan Cossney. He described a connection class that he developed for
Access 2007. I only briefly read the paper, and don't really know
whether it's based on the same idea, but somehow it used an
intermediary MDB file to achieve security in A2007. You might want to
check it out, too.

www.pdtltd.co.uk/pdtl/Access2007/Access%202007%20vPPC.pdf
 
Yeah, I can dredge out some old stuff that I did. It must be about 5
years ago now that I was playing around with this idea.
Click to expand...

Example files posted on http://www.geocities.com/jacksonmacd/

I tested the idea of two backends with a table link between them using
A2003. A link between the backend files *does* work, so a three-MDB
configuration is feasible. However, the #1 MDB must be in a share
that's visible to the #3 MDB (FE). Therefore, I overstated my response
to the original message, but the original concept still does work.

The link-between-backends *could* provide another level of obscurity
to keep the data away from prying eyes, but it's an admittedly kludgey
method. #1 MDB would be in a hidden share. #2 MDB would be in a
visible or hidden share, and would have Table Links to #1. #3 MDB FE
would be on the workstation and would contain a Reference to #2 (a
place where a snoop is unlikely to look).

Makes about as much sense as writing a homegrown Replication system
;->
 
Example files posted on http://www.geocities.com/jacksonmacd/

I tested the idea of two backends with a table link between them
using A2003. A link between the backend files *does* work, so a
three-MDB configuration is feasible. However, the #1 MDB must be
in a share that's visible to the #3 MDB (FE). Therefore, I
overstated my response to the original message, but the original
concept still does work.
Click to expand...

Is that an A2K3-format MDB? If so, can you upload it in A2K format
instead? I have access to A2K3 on a client terminal server, but
would rather not use their TS for personal work (I have only A2K and
A2K2).
The link-between-backends *could* provide another level of
obscurity to keep the data away from prying eyes, but it's an
admittedly kludgey method. #1 MDB would be in a hidden share. #2
MDB would be in a visible or hidden share, and would have Table
Links to #1. #3 MDB FE would be on the workstation and would
contain a Reference to #2 (a place where a snoop is unlikely to
look).

Makes about as much sense as writing a homegrown Replication
system
Click to expand...

Well, some people have to do that because of restrictive IT policies
(check out the 100+ post thread in
microsoft.public.access.replication on that very subject).
 
Back
Top