Access security

[Leo_Polla_Psemata]

Well
I am not an IT, I used to be a very good excel user some years ago, then jump to access.
Now i have developed, in my small business team, a very good application which deliverers a very
large amount of daily routines, checking, reports and so on.
It holds several sensitive info as well.
We are more than happy with this access.
There is only one small niche in the rear side of my head.
This application can very easily be copied and then travel outside my company together with these "sensitive" info pieces..

Is there any way I can secure so that this database works ONLY if it is siting in a specific server?
Copy paste to an outside environment, doesn't open... doesn't work and is self destructed?

 

[The_Doc_Man]

Short answer?

No.

It is possible for the DB to "walk" and then be used for someone else to import your data to a new, blank database without ever actually opening the application and incurring the code.

There is such a thing as encrypting a database using a password. But everyone has to have the password to use it. Let me expand your niche in the rear side of your head... what if the person who takes your database for a walk is one of your users who has the password anyway?

At least based on SOME studies, the U.S. Navy was aware that the greatest threat to security wasn't a hacker. It was a disgruntled or mercenary insider. External threats were not discounted, you understand, but we had to undergo all sorts of training to learn how to spot insider threats, social engineering threats, and threats based on careless operational practices.

One possible step to secure things a LITTLE bit better is to make your physical configuration and network configuration tougher to crack. However, this can be VERY expensive and you have to use a risk/reward decision method to decide how far you want to go with this.

1. If you haven't split the DB before now, split it and upconvert the back-end to something like SQL server.

2. Protect the back-end on the SQL server with a password and/or some other method of authentication. You could also use domain-based group identifiers as a way to protect your data (in addition to passwords, not instead of passwords) such that if a user is not a member of a specific domain-based group, disallow the contact.

3. Put a firewall around the SQL server that restricts the addresses from which it will accept connections.

4. Be sure to have some kind of logging management for the SQL server so you know who connects and for how long. You will begin to develop profiles of "normal" use. Then if someone logs in to steal your sensitive data, you might have an unusual session (in our shop, an "outlier" session) that you can narrow down to a particular user who could then be confronted.

In such an environment, it becomes harder for someone to steal data. But not impossible. Leo, if you ever come up with a really good solution to this problem on your own, you could retire from day-to-day stuff and become a high-paid security consultation.

 

[Leo_Polla_Psemata]

Thanks Doc Man
I understand what you say but sql servers back up, i am not capable of doing it.
I would like to protect data base from users who are not hackers but they are capable of coping pasting files and go for a free ride.

I don't want passwords.

I wonder IF there could be a "file" somewhere in the server which provides a kind of "silent password", db is linked to this file and works as if there is no password.
You copy paste but you, simply, don't know anything about the other "silent file" , then db just doesn't work/open etc , or even better, freezes the PC where you are trying to open.

This is what I could think but ....

Thanks anyway for the enlighten.

 

[The_Doc_Man]

Whatever you can devise, someone else can decipher. If they take the file for a walk, do the "import to a new file" trick, and look at your code, they can figure out what you are doing.

I understand you don't want password, but that is now Access encrypts the DB, based on using a password as the encryption key. Without that you can't encrypt the database in a way that Access could use it.

That "file" you are talking about as the hidden password? That is what is called "security through obscurity" and works UNTIL someone figures out what was being obscured.

If you can't manage an SQL-server solution and don't want a password-based encrypted solution, you have essentially said "NO" to the most common ways to protect a DB.

There is the outside chance that if you are a good enough programmer, you could build a DLL file that included some COMPILED code to do a lookup of some machine parameter and if that aspect of the machine wasn't there, the code could die. But if it was written in Office VBA, that can be decompiled.

There is no quick and dirty solution to the problem.

 

[gemma-the-husky]

what you can do is keep the code itself in a safe environment, and issue your users a compile mde or accde file.

This prevents other users seeing your code.

There are methods of protecting the database so that (for example) start up code can verify that the application is running on an approved machine. Generally this involves reading some information from the machine - and generating a check-code from that information. Installing the app on a different machine will cause the check-code to fail.

 

[HiTechCoach]

If your data is truly sensitive then asking for an additional password to get access would be expected.

At minimum you must use passwords that change every 90 days for anything you want to protect.

If you are in a Windows Domain/Active Directory environment where all users have their own user logon then you can piggyback on this. You would develop a Single Sign On method that uses the Windows Authentication for access control. The user only has to enter their password for Windows once. Also use Active Directory folder permissions to restrict access to the folder with the databases. If the database get copied it was one of the user or someone using their credentials.


Securing an Access database is not easy. Your security goal should be to make it very difficult for someone to Crack. That requires lots of levels of roadblocks. Hopefully they will give up before they get passed all the levels.

Well
Is there any way I can secure so that this database works ONLY if it is siting in a specific server?

Yes, or at least have made it very difficult to run anywhere else.

I do use an SQL Server to store the data. This make copying the back end much more difficult. Most users will not be able to do it.

I also use a licensing server to determine if the front end can be run.

You may also want to look into this: ActiveLock - Free Copy Protection


I know this is generic information. I can't give you more specific details in the open about what I actually use.

Publishing security methods on the web would make it much easier for anyone to defeat. That is why you are not finding any good security methods on the public/open web. Security methods must be kept secret.

 

[CJ_London]

password protecting the backend is the best you are going to be able to do. The trick is to make the password as obscure as possible in the front end - and don't have it hard coded, it is relatively easy to open a .mde/.accde in notepad and look for hardcoded values.

You haven't said which version of access you are using but .mdb level of encryption is not very high, .accdb is much higher.

You also need to consider what the user has access to when using the app - can they run a report that lists all clients and their details for example? Something they can simply send to a pdf and email home.

Also, disable or monitor copy in all its various forms (ctrl-C, rightclick options etc) to prevent users copying a datasheet, whatever and pasting to excel, notepad and the like.