From what I've read a recent version of FileMaker Pro being used by FileMaker Server will encrypt itself, if you set it to do so, when it is closed on the server. (Comments please).
Server doesn't use Pro; that's a bit of a weird sentence.
And Server does not auto-encrypt files or data.
There are 3 types of encryption available to use:
- encryption at rest (EAR): set by using the FMPA developer tool. Encrypts the whole file when not in use.
- encryption in transit (SSL): as data flows between FMP/Go/WebDirect/WPE and FMS. Provided that an SSL cert is used on FMS
- field-level encryption (new in 16): the ability to encrypt data in a field. Up to developer to use it or not.
Fortunately someone updated my post
Of course I meant the recent version of server using FileMaker Pro data files.
I was referring to ear but did not remember the term. Thanks.
It's good to see that FileMaker Ink is providing more and more encryption abilities. Too bad you have to buy Advanced to use them...
1 of 1 people found this helpful
I thought the same thing when this news came out. It is so very easy to secure FileMaker databases today, and in this instance it appears that EAR would have solved the problem if the data was copied as an entire file.
If you have a client that is hosting a data sensitive solution, then not allowing exports for most/all users is a frequently overlooked must. Most common way for large sets of data to walk off site is by simple exports. In the voter DB case, a large delimited text file was wide open on the server, and fro what I read may have been part of a data warehouse effort.
If there is a possibility that someone in IT may take a copy of the DB elsewhere (always the possibility of a disgruntled employee, etc.) then EAR is a must. I started adding EAR to many of my hosted solutions.
In fact, adding EAR helps me as a developer know that some of my best work stays at the client's site, even when they have full access (less the EAR password) to their solutions. Some clients require full access, but EAR gives me at least some security in ownership of the work, while the client owns the data and can control whether exports, SSL, and field exception are employed.
Maybe it's time to check your own solutions and servers:
- How many databases have no encryption enabled?
- How many databases do have a standard password or even no password for admin?
- How many servers do have the FM Sample database without password?
- How many solutions allow you to export all data to a text file?
- How many solutions may allow someone to delete all records in a table?
- How many servers do not have SSL with your own certificate where you keep the private key secret?
- How many have a local admin account with standard password or just run with local user logged in?
- How many servers are actually in a logged room where nobody can go inside unnoticed?
There are some basic things everyone should do to prevent such a data leak on their own servers.
I just read a joke in a local give away newsltetter:
The best way to get a correct answer on the internet is to post a wrong one.
I could have written that myself...
Remember when USB sticks were 8 Megabytges and cost $99?
Today you can buy a 256 Gbyte flash card the size of a postage stamp and it is hardly visible. $30 or less on sale.
The USB ports in the back of the computer were prime locations for clandestine data copying.