Protecting data storage with explicit credentials against ransomeware

You could place your backend on a share not reachable from the shares that users will map (with drive letters).
Then link to the backend via its UNC name.

/gustav

Not sure this is relevant, ...but if you are running a "Standard" Access environment, ...each user will have a "Locked" version of the database on their desktop.
By "Locked" I mean it will be a ACCDE file.  Meaning that it will not contain any code that a hacker could access directly.
I wont be "locked" in a technical sense.  
It will be locked in that the user will not be able to change any forms, reports or VB code, ...but they will still be able to add/edit data.

If you look at the way Ransomeware is "Distributed", ...your first line of defense would be to have a reliable Back up strategy.
(This is not always full proof, ...but it is better to have a "chance" of recovering your data than non at all.)

Second, ...protect your email systems, thus preventing questionable emails from even getting to the users workstation.
Third would be to have virus detection that will automatically shut down the attack once detected.

The way these infections typically work is that the infect a PC that has some level of "access" to the sensitive files.

We could go on for days on this, ...but I am trying to confine the discussion to MS Access environments.

Lets see how other Experts expand on this...

JeffCoachman

Gustav,

I don't believe that will help.  The Bad Rabbit ransomeware, for instance, is able to propagate via network shares.  I am attempting to isolate the data share from the user to better protect it.

Jeff,

I have those protections in place (mail filtering, antivirus, real time backup, etc.) However, I would like to remove the individual user's permissions from the data, since that is the most valuable asset.  By essentially giving the code base a credential to the data store that is not accessible to malware on an infected machine, I hope to further enhance my data security.  

Ben

>  The Bad Rabbit ransomeware, for instance, is able to propagate via network shares.

Then you can't isolate the backend.

Move the data to a server engine like SQL Server or MySQL.

/gustav

There is a need to avoid RDP and SMB as they are exploited by ransomware for mass spreading. So to call for data, other means would be through service calls via APIs to the server, that said, it would be via RESTFUL calls with SAML or OAuth supported. Potential code revamp though to turn backend into sort of services (eeb methods) for appl running on client to subscribe for data retrieval or update..

If you're using an Access backend, the location of that backend must be on the same physical network as the FE, and users must have Read, Write, Create, and Destroy permissions on the Folder (they don't need Delete permissions on the BE File itself, however). As far as I know, you cannot provide other credentials to connect to your ACE backend (or Jet, if you're still using older Access formats). Gustav's suggestion to hide the backend in a downstream folder is about the best you can get. If you were to remove the permissions for a Standard User to get to the database location, then the database would become unusable.

Scott,

Thanks for the comment.  I'll have to ponder that for a while. The engineer in me always says "there must be a way."  Given today's security environment, I really don't like having core data exposed to any infected machine :-(

Thanks,

Ben

Gustav,

In most cases, we have already migrated data to SQL,  but we are doing a lot of e-doc storage as well.

I really don't like having core data exposed to any infected machine

If you're storing core data in an ACE or JET database, you're significantly increasing your risk of data leaks, exposure, etc regardless of what measures you put in place. ACE or JET simply are not as secure as other storage systems (MSSQL, MySQL, Oracle, etc), and they never will be. ACE or JET databases are file-server type systems. If someone can get to the file and copy it, they can host it on their own system and take their own sweet time to get into the file.

Bottom line - if you want true data security, stop using ACE/JET to store your data and move to a server-type environment, as Gustav suggested earlier.