Re: Is UserLevel Security Really Necessary?
- From: "Neil" <nospam@xxxxxxxxxx>
- Date: Mon, 18 Jun 2007 06:27:48 GMT
Hi, Larry. I agree with everything you wrote re. using an Access back end
over a WAN. However, one question for you. Since this person seems to be
using Access merely to append records to the back end, and will not be
retrieving any data from that back end, doesn't that change the formula a
bit? It seems that an append-only database is a different beast from a
read-write database. What do you think?
Neil
"Larry Linson" <bouncer@xxxxxxxxxxxxx> wrote in message
news:CUodi.1025$5h6.417@xxxxxxxxxxx
"Earl Anderson" <isobadd@xxxxxxxxxxxxx> wrote
A split Access-Jet database is unsuitable for
use over a WAN. If you are planning an Access
client application to a server DB at a central site
over the WAN, or access via Windows Terminal
Services, security considerations will be different.
Larry, not to be a pain-in-the ass, but I am/was
planning to employ this over a WAN.
That much was clear. My question was "what configuration do you hope to
employ over the WAN?
Is there either a reference you can point me to
or else tell me WHY Access is "unsuitable for
use over a WAN"?
That's not what I said... I said, and quote from the paragraph above "A
split Access-Jet database is unsuitable for use over a WAN." A bit of
Googling in this newsgroup, or in microsoft.public.access.multiuser, would
explain, or a visit to MVP Tony Toews' site,
http://www.granite.ab.ca/accsmstr.htm.
But, just to summarize... the Jet database engine is not a _server
database_, but a _file-server database_. All the actual data retrieval,
storage, and manipulation is done on the user's machine. The back-end
datastore on the server or remote shared drive is used just as it would be
if on the local drive... it's not "the whole database has to be brought
across the network" but all the data that would be retrieved from the
local hard drive has to be brought across. For example, if you have a
table that is indexed on MemberID, and your query selects a particular
MemberID, the MemberID index will be brought across (or at least enough of
it to locate the particular Member ID) and then the specific Record will
be brought across. If your table is not indexed and you Query on a
specific value in a specific field, it is possible that the entire table
will be brought across the network. WAN speed is just not sufficiently
fast for that to be practical.
However, if your Access front-end is a _client_ application to a true
server DB such as Microsoft SQL Server, where the request is sent over the
network, but the processing of the index, and extraction of the data is
done remotely by the server DB, a WAN will generally be OK. Or, if you
have the necessary license for accessing the server via Windows Terminal
Services, and you have sufficient computer power on the server, each
user's database work will actually be run on the server itself.
We are pointing out what _can_ happen, not what necessarily _will_ happen.
But, yes, you are correct -- I have long said, "If your data is worth $150
to anyone, better not rely on Access/Jet security to protect it." That's
what some "password recovery software" sells for (you or I might call it
"security crack software").
On the other hand, the server DBs have better security. MS SQL Server is,
IMNSHO, about the easiest to learn and administer, but has an initial cost
plus a license is required for each user. There are open-source
databases, e.g., MySQL and PostgreSQL, which do not have the initial or
per-user charge, but for which you may need to contract "services" for
helping you solve problems, etc., and they are not as easy to learn and
administer.
It's not, necessarily, that you implemented something erroneously and left
security holes. It is that Access' and Jet's security leaves a great deal
to be desired if you really want close control over your data. "Sucks" is
pretty strong, because it is adequate to keep user's from stumbling over
their own feet and ending up somewhere in the database that is none of
their business.
But, if you use Access to front-end a server DB as the datastore, you have
a lot more security. But no one's security model is _perfect_.
Larry Linson
Microsoft Access MVP
As far as more details, the path that points to the backend is a secure
network path that only I can authorize IT-Security to permit an
individual access to it. Although I'm not concerned about the guards
getting to other elements of the program (they only have the GAL data
immediately available to them), it appears that with some Access
know-how, it would be possible to change data of the activitiy log.
From what I'm gathering from you, Gunny and Rick, Access Security Sucks.
It appears that the most I can do if I want to use this form of
documenting log entries is to employ network security as well as ULS for
this endeavor and still, that's no guarantee that data can not be
manipulated once entered.
I think the larger question/issue is if it (data manipulation) can be
done here in my Access app, can it not be done in any Access app?
Thx...
Earl
.
- Follow-Ups:
- Re: Is UserLevel Security Really Necessary?
- From: Larry Linson
- Re: Is UserLevel Security Really Necessary?
- From: David W. Fenton
- Re: Is UserLevel Security Really Necessary?
- References:
- Is UserLevel Security Really Necessary?
- From: Earl Anderson
- Re: Is UserLevel Security Really Necessary?
- From: Larry Linson
- Re: Is UserLevel Security Really Necessary?
- From: Earl Anderson
- Re: Is UserLevel Security Really Necessary?
- From: Larry Linson
- Is UserLevel Security Really Necessary?
- Prev by Date: Re: Is UserLevel Security Really Necessary?
- Next by Date: Diagram box in access
- Previous by thread: Re: Is UserLevel Security Really Necessary?
- Next by thread: Re: Is UserLevel Security Really Necessary?
- Index(es):
Relevant Pages
|