Re: Is someone hacking into our database?

Thank you all so much for your help -- it has been invaluable. I have one
more question, though. When I talked to the other person who is technically
over the databases, she said she talked to a consultant the agency hired to
look at our data systems, and the consultant said that you never, never want
to use Access databases to store large amounts of data like ours (our backend
is only about 90-100 mb in size) because the database goes screwy and begins
deleting its own data. I responded that I was very surprised at this because
my understanding was that Access could hold a lot more data than we have. I
also said that I heard that the real issue with using Access is that you
never want to use it to store sensitive client data, but have never heard
that it eats its own data if it gets too big. But -- I just wanted to check
this out with you. Does Access go haywire if it gets too big, causing loss
of data?

Our agency is currently working with a consultant (the one who made the
statement about Access eatings its young) to look over our systems, servers,
etc. and recommend and build (she's also a programmer, I guess) a system that
is "right" for us. I have reported to my superivisors the security issues of
using our access database for our sensitive client records, and that I'm
concerned for how to keep it secure while this consultant is building a
different system, but that I know of no way to keep it secure (due to the
possibility of password hacking) -- but (one more question) do you know of a
way to keep it secure while waiting on a new system?

Thanks so much for your help. :-)

"Joan Wild" wrote:



--
Joan Wild
Microsoft Access MVP

eagle wrote:
I'm still thinking about your reply. I guess I'm not completely sure
what you mean by someone changing things from their standard
system.mdw workgroup. I changed to that workgroup, then opened the
secured workgroup file, and could view things, but wasn't able to
change anything.

OK, but are able to add users. You are logged in (silently) as Admin, which
is a member of the Admins Group in system.mdw. Therefore you are able to
add users in that workgroup. However, you are only adding users in that
workgroup. You aren't able to add this new user to any of your secure
groups, because they don't exist in the system.mdw. Groups/Users/passwords
are stored in the mdw. Permissions are stored in the mdb.

The only way I was able to make changes
in the secured workgroup file was to login to the database via the
secure workgroup, and make changes via Tools, Security, User and
Group Permissions....but only when I logged in as the SuperUser (with
all permissions). Does this make sense?

Yes it does. So what you are saying is that someone is creating a new user
in your secure mdw. Only members of the Admins Group (or someone with
administer permission) can do this.

I just know that something
bad is happening with the database here, and is full of sensitive
client information, and I am the one responsible for it, and need to
nail down what is happening so I can stop it fast. Please help.....

If you are dealing with such sensitive information, the data shouldn't be in
a Jet database. Access security can be broken (just do a search at Google).
You should put the data in a more secure database, such as SQL Server. You
can still use Access as the frontend to this data.


--
Joan Wild
Microsoft Access MVP



.

Relevant Pages

  • Re: Access Security not secure
    ... You should secure it manually. ... > In your test with using a new workgroup and running the> wizard it was in access2000 then again in access2002 ... >>> to work well until I try to access the database on the ... >>>>> I created the Administrator and added him to the> admin ...
    (microsoft.public.access.security)
  • Re: Baffled By Security Wizard
    ... I did in fact add the Group to my secure workgroup. ... I'm not clear on why importing the ... objects into a new database was critical. ...
    (microsoft.public.access.security)
  • Re: Sticking with a defined Workgroup.
    ... workgroup file called system.mdw. ... So when you 'join' your secure mdw on the server, it is now the default mdw ... My trouble is that when I distributed my secure database by putting ...
    (microsoft.public.access.security)
  • Re: Security - Security & User Accounts
    ... You are currently joined to the workgroup file you secured ... password set so Access silently logs you into the database ... and then how can I set up secure logins for ...
    (microsoft.public.access.formscoding)
  • Re: Run-time error 3033
    ... > only users who can change the value of the property, are members of the ... > Admins group of the workgroup file which was used to secure the ... > database ... > So I suggest that you log on as a member of the Admins group, ...
    (microsoft.public.access.security)