DMS Facets

Relating several topics, including IT, Microsoft Access, sports administration, and micro-ISV business.

Access Security

1

Management by Technology

security When planning and designing a Microsoft Access application, the question of the security of the data has to be carefully considered.

Similarly, one is called upon, from time to time, to discuss this aspect in technical forums and newsgroups.

Of course, from the technical angle, there are many aspects that could be discussed – and indeed they have been, many times in many places.  Hiding the database window, disabling the bypass key, deploying as MDE/ACCDE, backend in SQL Server, etc.  But that is not my main focus here.

Nor do I want to diminish the importance of attending to the question of data security in general.  However, I think we have to recognise that how critical a consideration this is, will vary hugely from one industry to another and from one application to another.

If security is highly critical, basically an Access application with a JET/ACE backend database is not the right tool for the job.  So?  There are millions of database application scenarios where security is not highly critical.

A few weeks ago, I was responding in a newsgroup to a question about preventing access to the backend database.  This person had realised that if anyone on his staff was sufficiently savvy, it would be possible for them to use various means to locate and connect to his application’s data.

This person had taken all the reasonable steps, as a developer, to make the backend database file difficult to find and open directly, and to make sure that the ordinary user would only interact with the data via the frontend application.

He asked what further steps he can take to prevent this hypothetical tech-savvy staff member from finding a way in.

I was discussing this over lunch with Lucy Thomson, fellow MVP, and she confirmed my viewpoint.  “People keep trying to use technology as a substitute for management!”

Exactly!  This is not a technical question.  It’s a management question.  It’s already patently obvious that you’re not supposed to mess with the database file.  It’s like a locked door.  It wouldn’t be too hard for someone with a screwdriver or bolt cutters to get in – but they would surely know they were doing something wrong.

Mr/Ms Savvy linking to the data file, or however they are going to do it, is hacking the company system. This is a serious offence. Make sure the staff know it will not be tolerated. Public flogging followed by instant dismissal for first offenders.

Expend your development efforts on building a great application. And apply management solutions to management problems.

One Comment

  1. Anonymous

    This problem has plauged me for quite a while in various scenarios.
    I have developed a solution which satisfies me.
    For my Access apps I use 3 files. Front End mde, Back End and a little mde called Start. Front End and Back End have passwords. Start is simply used to start the Front End with appropriate password then Front End links to Back End with password – Works fine.
    I also use validation to track copying of Back End. During Start of Front End I open then close the Back End (mde)which has an Auto Excec macro in it to record the Motherboard serial number of the Back End home PC.
    If the seial number ever changes we have a move or copy. This sets up a Need for Validation on the Main Menu with 10 days to do something about it. I base the validation code on a fiddle of the date serial number.

    Reply

So, what do you think ?