If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Advice on securing a sensitive Access database
I wonder if someone could give me some pointers on the following.
I need to securely encrypt an Access 2003 database currently sitting on a server with multiple users linking to it from their individual PCs via an Access 2003 front-end. I need a hardware/software solution that will:- 1. Encrypt the database on the server so that a copy of it is of no use to anyone. This is to cover if the server is stolen. 2. Ensure that only authorised users directly connected to the network can access the database and preferably only via the designated Access front-end database. 3. Authorised users cannot get a decrypted copy of the file via their PCs - i.e. cannot use Explorer or similar to copy the file in decrypted form. I presume that the solution would include hardware and software elements. I would be grateful for any guidance. Many thanks. -- Les Desser (The Reply-to address IS valid) |
#2
|
|||
|
|||
Advice on securing a sensitive Access database
"Les Desser" wrote in message
news I wonder if someone could give me some pointers on the following. I need to securely encrypt an Access 2003 database currently sitting on a server with multiple users linking to it from their individual PCs via an Access 2003 front-end. I need a hardware/software solution that will:- 1. Encrypt the database on the server so that a copy of it is of no use to anyone. This is to cover if the server is stolen. 2. Ensure that only authorised users directly connected to the network can access the database and preferably only via the designated Access front-end database. 3. Authorised users cannot get a decrypted copy of the file via their PCs - i.e. cannot use Explorer or similar to copy the file in decrypted form. I presume that the solution would include hardware and software elements. I would be grateful for any guidance. If your data is really that sensitive/valuable then I would suggest using Oracle or similar since Access security can be easily broken. Keith. www.keithwilby.com |
#3
|
|||
|
|||
Advice on securing a sensitive Access database
"Keith Wilby" wrote in message ... "Les Desser" wrote in message news I wonder if someone could give me some pointers on the following. If your data is really that sensitive/valuable then I would suggest using Oracle or similar since Access security can be easily broken. There is another venerable DB that is used daily by the US Army, Airforce, Navy and the FBI for the one of the very reasons you seek. After all, it was originally invented to track the engineering data and the parts to the Space Shuttle by Boeing, then later ported to the PC environment. I have used it since 1983 and quite a few of my colleague developers use it for medical records applications which require a similar security requirement. www.RBase.com Still very much alive and used worldwide where other solutions can't make it work. Keith. www.keithwilby.com |
#4
|
|||
|
|||
Advice on securing a sensitive Access database
Les Desser wrote:
I wonder if someone could give me some pointers on the following. I need to securely encrypt an Access 2003 database currently sitting on a server with multiple users linking to it from their individual PCs via an Access 2003 front-end. I need a hardware/software solution that will:- 1. Encrypt the database on the server so that a copy of it is of no use to anyone. This is to cover if the server is stolen. I think you'd want a copy that is of use to someone. Hmmmm...zip it up and put a password only the big cheeses know. 2. Ensure that only authorised users directly connected to the network can access the database and preferably only via the designated Access front-end database. Network access rights. Usually the front end is run from the C drive. What's more important? The program/app? Or the data? 3. Authorised users cannot get a decrypted copy of the file via their PCs - i.e. cannot use Explorer or similar to copy the file in decrypted form. Network access rights once again. Remove the Copy right. I presume that the solution would include hardware and software elements. Mostly OS elements. I would be grateful for any guidance. Many thanks. Friction http://www.youtube.com/watch?v=Mh9a5_3ATHY |
#5
|
|||
|
|||
Advice on securing a sensitive Access database
In article sOqLj.23706$4O1.6011@trnddc03, Larry Linson
Thu, 10 Apr 2008 15:58:16 writes [...] Thank you for your comprehensive response. Also thanks to the other posters for their ideas. The background is that the Access application has been developed over many years and it is not really viable to re-write it. Due to the prospect of some commercially sensitive data being now stored in the database, it has become desirable to secure the data. I do not have major concerns about the Access front end as 1. the staff using it are trustworthy 2. the data would have to be extracted table by table 3. the front-end is an MDE and I think I can securely (reasonably) hide the table view. To steal the data via the front end (or an alternative front end once Access security had been broken) would be non-trivial and they would have to work within the office (as the data would be encrypted). My main concern is how to, on the one hand, encrypt the data on the server (TrueCrypt?) so that if the server is stolen the data cannot be read, and on the other hand, allowing the Access front end to read the decrypted data but somehow blocking access to the decrypted data to the Windows file copy facility. As far as I can see, once the decrypted data is visible to the PCs running the Access front end, it is also a matter of a few seconds to copy the whole decrypted data mdb using Explorer. I regret that I don't have more encouraging words for you. Sounds like I have a problem -- Les Desser (The Reply-to address IS valid) |
#6
|
|||
|
|||
Advice on securing a sensitive Access database
Hi Les,
This is a problem that I have solved once before, and I can tell you that it is fraught with dangers. I have managed to incorporate AES 256 bit encryption on the individual tables, complete with a user control / access system. I must stress just how much a pain in the arse this was / is. The way that I achieved this was to use encryption the same way the EFS does. Basically it works like this: 1/ You need to generate a *RANDOM* key to be used for the AES algorithm for each table. I used GUIDs for this and adapted the GUID to a key. 2/ You need to make a 'master' Asymettric key pair to act as a data recovery in case of emergency. Use a different GUID. 3/ You take the 'master' key pair, and using the private key encrypt the AES key for each table, and store the encrypted AES key as a table property of your defining. 4/ Lock away the AES keys, as well as the 'master' key pair. 5/ At the field (contents) level you use the AES encryption, specific to the table, to encrypt the contents of each field. What you should now have is the entire database encrypted with AES encryption. (I will try to find the links to the VBA code for this). At this stage no user can access the data in any meaningful way, unless they happen to have a neat way of breaking either the symmetric encryption on the fields or the asymmetric used to encrypt the AES key itself. Now comes the user part: For each user you need to generate an asymmetric key pair. This is in turn used to make an encrypted copy of the AES key, which is attached to the tables as a property with a name of your choosing. I suggest the property name either be the user name / id, or some other easily identifiable term that is specific to each user. In this way you can also only give users access to the tables that they need simply by making sure that you dont issue them with an encrypted copy of the AES key for that table. I suppose you could extend the model further even to the column / field level if you wanted, but I thought that to be overkill. I used the public part of the key pair to encrypt the AES keys, and as per normal kept the private part private :-) It was my intention to eventually use certificates with a token to handle this but the project never went that far. Anyway, back on with the task at hand. We had two options for handling the private keys with this. The first was to have them stored in files on disk / usb key etc.., or alternatively to have them stored in a db, themselves encrypted. We eneded up using the second system due to practicality. Users were asked for a username / password to access the system. The password was MD5 hashed, and in turn the MD5 hash was used to decrypt the private key again using AES. The way that we knew if the password was correct was to have the MD5 hash also stored in encrypted format with the private key. This became the weak point of the system, but as I said we didnt get to the point of using certificates and tokens. If the username / password combo was able to successfully decrypt the AES encrypted private key it would also successfully decrypt a copy of the MD5 hash associated with that key. This was done in a table with 3 columns, username, password, private key. The administration of this was done through a separate database / app that was not accessable to anyone except the administrators. It was kept on a secure usb key (if you can call them that). I am sure you can think of ways of securing the physical media. User key pairs were added as needed and expired / removed as needed. I am sure that you could also implement time restrictions, as well as network card or IP address restrictions to the application. For example it is possible to gather the MAC address of a network card, as well as the IP address of the card as a means of testing the 'local' environment of the application, though I would have to think about how you would secure / administer that data. In the end it comes down to how far you want to go to secure the data and is it worth it? The method described above will certainly give your data a heavy level of encryption by most current standards, but that does not necessarily mean that the model suits your purposes or is suitable for the task. The app I wrote is currently stored securely and I do not have access to the finished code, however I do remember that I located a lot of what I needed freely available on the net. I will have a look over the weekend and see if I can locate the sites where the code came from for the different algorithms. Hope this gives you some food for thought. Cheers The Frog |
#7
|
|||
|
|||
Advice on securing a sensitive Access database
I need a hardware/software solution that will:-
1. Encrypt the database on the server so that a copy of it is of no use to anyone. This is to cover if the server is stolen. I have not used any strong DB security; but as others have pointed out, someone with physical access to your serve can with time break any encryption you apply. You need secure the server, at least in a locked room in a building with some type of monitored alarm system. That way your random thief would only get basic office equipment. Using Windows security; your server hardware may be the only thing of value to an office equipment thief. A more sophisticated thief may only take your backup media or better yet, break-in though the internet. |
#8
|
|||
|
|||
Advice on securing a sensitive Access database
In article , "paii, Ron"
Fri, 11 Apr 2008 08:48:26 writes I need a hardware/software solution that will:- 1. Encrypt the database on the server so that a copy of it is of no use to anyone. This is to cover if the server is stolen. I have not used any strong DB security; but as others have pointed out, someone with physical access to your serve can with time break any encryption you apply. You need secure the server, at least in a locked room in a building with some type of monitored alarm system. That way your random thief would only get basic office equipment. Using Windows security; your server hardware may be the only thing of value to an office equipment thief. A more sophisticated thief may only take your backup media or better yet, break-in though the internet. I accept your comments and recommendations. My main problem still exists even when physical security of the server has been addressed. -- Les Desser (The Reply-to address IS valid) |
#9
|
|||
|
|||
Advice on securing a sensitive Access database
In article
, The Frog Fri, 11 Apr 2008 05:33:58 writes [snip fine detail] Phew! I have given it a quick read and there is a lot there that I do not understand at this stage, but it gives me hope that a possible solution is appearing. I will have a look over the weekend and see if I can locate the sites where the code came from for the different algorithms. That would be most useful. Hope this gives you some food for thought. Thank you - it gives me hope. -- Les Desser (The Reply-to address IS valid) |
#10
|
|||
|
|||
Advice on securing a sensitive Access database
Hi again Les,
Security is depth is certainly the best way I can think of to approach the issues surrounding any data confidentiality. There are many factors to consider when approaching such a thing, and most of them are situation dependant on how you address them. For this you need to do a proper risk analysis, which I think is probably going beyond the scope of this forum. If you want to approach such a thing I am happy to try and steer you in the right direction, so just drop a note in the forum here. As for the 4k keys, you must understand that there is a difference in cryptographic types (algorithms) used. Symmetric and Asymmetric. AES is a symmetric cipher, commonly used with a 256bit key strength. A symmetric cipher, in this case AES, is quite fast, safe, and considered strong for securing information, but it suffers, like all symmetric encryption, from a problem known as the 'Key Distribution Problem'. Basically it means that you use the same key to encrypt and decrypt the data. If you want to send the data to someone with a symmetric cipher then in order for them to decrypt it they need to know the same key you do - but you shouldn't transmit the key with the data! So how do we get around this problem? The answer lies in Asymmetric encryption. Asymmetric encryption allows us to have a public and private key which are distinct and separate from each other, but at the same time directly related to each other. The way it works is that you can encrypt something with your Private key (called signing in most instances), and anyone can acquire (safely and without concern) a copy of your public key and see that the data came from you. Only your public key can be used to decrypt the data encrypted with the private key. Now if we reverse the situation, and we encrypt the data with the public key, only the private key can decrypt it, which means that anyone can encrypt something, send it to you, and only you with the private key can decrypt it. The difference between the two keys is one of information. The private key contains enough information to be able to reproduce the public key at will, but the public key is built in such a way that to reproduce the private key is extremely difficult (but not impossible!). So, what do we do to make the public key really secure? We use giant 4k keys that make the problem so large / hard to solve that for all intents and purposes it is unbreakable / considered secure. The problem with Asymmetric encryption is that it is slow by comparison to Symmetric. Slow by a long way. So how do we solve the problem of your DB encryption? We use Asymmetric to encrypt the Symmetric keys. The 'heavy lifting' of encryption / decryption of the data is actually handled by the AES cipher which is relatively fast, and only the decryption of the AES keys is done with the slower Asymmetric cipher. This keeps the system and data both relatively fast and safe, and also gets around the key distribution problem. So, crash course in cryptography aside, here are some links that I have used for the different algorithms and components: MD5 http://www.di-mgt.com.au/crypto.html#MD5 RSA http://www.di-mgt.com.au/crypto.html#dhvb AES http://www.frez.co.uk/freecode.htm#rijndael You will also find some useful code implementations he http://www.freevbcode.com/ShowCode.asp?ID=3779 I hope that this gets you on your way, and you are successful in implementing this for your needs. I will monitor this thread if you need further help with this. Cheers The Frog |
Thread Tools | |
Display Modes | |
|
|