How to protect runtime DB from being imported?

[hksic]

We want to create some runtime solution to our clients which containing critical information. They need to modify, create and delete the records but we do not want them to export the records. We have disabled the export permission in their account. However, if they create a FP7 database and use the import function. All the data are extracted within mins. How can we prevent that?

All the data are very sensitive and we do not want them to export. Any solution?

[Barbecue]

Well this is a pretty old question, so probably nobody cares, but I'm going to answer it anyway because it involves one of my pet peeves.

In this situation, it's impossible to prevent someone from collecting your data in bulk. Absolutely, unequivocally impossible. All you can do is make it inconvenient.

With respect to the specific importing into FM7 question, you can prevent this by encrypting the data. There are several plugins available that encrypt data in FileMaker. Encrypt the data when saving, decrypt as needed for editing/display.

This requires taking complete control of the user interface, but that's what you must do anyway if you want good security. Then if someone does an import into another file, they will still see your data, but it will be encrypted, and of no use, unless they are able to determine your encryption method and key, which they would need access to your scripts to do.

Of course, if your solution stops working and your client has irretrievably lost mission-critical data because of your encryption, you're looking at one seriously irate client, and the room will fill with lawyers in no time flat.

Encryption of the data in the database does no good if you allow users to print reports of the data. Any print job can be redirected to a file, and from there the text data extracted for whatever use. This is not even slightly difficult. So no printing allowed.

Even after all that, you're still not in the clear. If users can view and edit records, they can collect the data. In fact, if the data can be shown on the screen, it can be collected. Unless you are actually monitoring the users, it's impossible to prevent them from collecting your data simply by browsing all the records one at a time. You can make this difficult by putting limits on the number of records someone can view in a given time frame, which will stop them from collecting data quickly enough to make it valuable, but will also almost certainly frustrate them and hurt their productivity.

After saying all that, as an administrator, I would never consider a product that required such restrictions. Either the data belongs to the customer, in which case you have no business keeping it from them, or it belongs to you, in which case you should probably be paying them for doing your data entry.

If you're providing the client with some sort of trade secret in your database, then a good strong contract and non-disclosure will be both easier and stronger protection than draconian data policing procedures. And when it comes down to it, if you can't trust your client to honor your contract and protect your secrets, you probably can't afford them as a client.

The real question is "Whose data is this?" If it's your data, why is the customer entering and changing records? If it's the customer's data, then why would you want to stop them from exporting it? If you're letting them mix your data with theirs, you're automatically making it their data by default.

So what's the answer? A strong contract, non-disclosure agreements, and due diligence on your part when vetting your customers. It doesn't matter how many technical obstacles you put in the way, if you don't have good legal support for your position when security is breached, you've already lost. And if you do have a solid contractual arrangement, you don't need such heroic measures to protect the data. Good solid basic security practices and some common sense will do the job.