Actually I'm glad you brought this up because this was bugging me. The justification we were given for on disk encryption of the files (on a device that isn't otherwise encrypted) was:
- The user would be required to use a smart key or hardware token to decrypt the database file at run time
- This would mean that the database files were only vulnerable when the hardware token/smart key was around
Last night I was thinking about this and I'm pretty sure this argument isn't valid.
There are exactly two ways that the database could be compromised. Either a human did it or it's programmatic.
If a human did it then it means that a human was able to physically get access to the machine while the hardware token/smart key was in use and get the file out. A related version would be that the human has legitimate remote access to the machine and legitimate
access to the user's account and uses that to copy out the files while the hardware token/smart key is in use.
If the attack is programmatic then it just means that the malware hangs out until the files are decrypted and then steals them.
Personally I find the second attack much more likely than the first in which case the defense of encrypting the file (but not the device) seems largely worthless.
But I'm happy to believe I'm missing something.