FMP on www - security overview?

[Ian Murphy]

My office has gotten accustomed to interacting with our custom DBs, and there is plenty of sensitive information in there (names, addresses, et c.). So I'm looking forward to telling senior staff that after a recent move & some structural LAN changes, I have a static IP set aside and a dedicated terminal and they'll be able to access their calendars and Rolodexes from home.

Before I go live with that, though, I'm thinking about security. We've always maintained this data on a closed network behind a firewalled router, so I've never used any particular measures (logins, passwords) to get access. If I'm going to putting people's home addresses on a public terminal, I need to.

So here's my setup:

A Win 7 x64 terminal running Windows, FileMaker Server, Carbonite, and Dropbox (and nothing else) is connected to a modem. I access it via RDC and FileMaker. Windows Firewall is on, and inbound connections are blocked. Network discovery, file / printer sharing, Public folder sharing are all off.
    
What's the local custom for allowing access? Do you set up a password and distribute it among staff? I see that FMS can restrict access to certain individuals (or accounts) - maybe that makes sense? Or can I restrict it to users who are running a copy of FMP that's authorized to my multi-volume license?

I currently publish an XML feed and plan to look into WebDirect. Do I need to take any steps to ensure that www search engines don't scrape this data?

Any and all input is welcome.

[taylorsharpe]

You probably should start off by reading FileMaker's Security guide at http://help.filemaker.com/app/answers/detail/a_id/13291/~/the-filemaker-security-guide

 

I would recommend you use a real server operating system and not Windows 7.  I recommend you use FileMaker security encryption that you turn on in the Admin Console to use AES 256 bit cypher to encrypt between the client and server.  In FileMaker 13, you can also encrypt at rest if you are worried about physical security (someone breaking in and taking the machine).  Security includes a backup plan including off site backups (e.g., in the cloud or maybe at an alternate office location).  You'll need a physical security plan such as locking the server room and limiting access to that room to those who need it.  You will need to set up privilege groups and assign people to appropriate privileges controlling what tables, layouts and scripting they can access, modify, delete, create, etc.  The enterprise method of handling User ID's is to make use of Active Directory on a Windows Server (or Open Directory on a Mac Server) and each person will have a User ID and password.  I personally set up many of my new databases using a 2nd factor authentication, usually with email as the 2nd factor.  You should have a firewall that opens only the ports necessary.  You should only be running the FileMaker service on the server and not other services per FileMaker's recommendations (e.g., don't also use the machine for Active Directory, File Sharing, etc.).  If you install a certificate for FileMaker service and turn on security encryption, then Web Direct is very secure.  But if you export files from FileMaker to somewhere else, you'll have to develop security accordingly.  And if you don't want to worry about Windows viruses and Trojans, you'll have a lot less exposure if you use a Mac OS X Server.  

 

The enterprise level of security involves documenting your security plan.  The International Standards Organization has a standard, ISO 27001, that steps through how to document security and have minimum security standards and it is a very thorough documentation and involves auditing, etc.  Or you can look at the US Governments standard for documenting information database security plans which developed by the National Institute of Standards and Technology (NIST) in their Special Publication 800-53 (current version is revision 4).  

 

I think some of the security plans described above are over kill and just document security you have hopefully already implemented.  If you follow the FileMaker Security Guide, you'll meet minimum levels good enough for Top Security for the US Government computers.  

 

The US Department of Homeland Security maintains a National Vulnerability Database to document all known vulnerabilities to various softwares.  I just did a search on FileMaker and there have only been 5 vulnerabilities documented since the year 2000 none since version 5 of FileMaker have been classified as a High vulnerability (the other 4 were all Medium level).  Compare this to Oracle that has 2585 vulnerabilities as of today and MySQL has 461 vulnerabilities.  Oracle's most recent was just in January and listed as a High vulnerability.  MySQL's last High vulnerability was this month (March 2014) and is a SQL injection attack.  While I'll never claim FileMaker is invulnerable, it certainly looks to have a lot less security issues than other major database platforms and this database certainly makes FileMaker seem to have a very good security record.  In other words, from the security perspective, FileMaker is a good choice.  

[Wim Decorte]

running Windows, FileMaker Server, Carbonite, and Dropbox

 

Make sure Carbonite is not backing up the live FM files and don't put your live FM files in the Dropbox folder.  Nothing should try and touch the live FM files except for FMS

 

 

 We've always maintained this data on a closed network behind a firewalled router, so I've never used any particular measures (logins, passwords) to get access. 

 

Most security breaches come from inside the network, not from outside the network.  If the data has any value and data integrity is important, it should always be protected by proper accounts and privilege sets.

 

 

 I access it via RDC and FileMaker. 

 

I could not make out whether that is also how you will let the users access the file.  If so: don't.  The FMS machine should not double as RDC machine.  If you let people access the OS on the FMS machine, all sorts of things can go wrong.

 

 

I see that FMS can restrict access to certain individuals (or accounts) - maybe that makes sense? 

 

Not sure what you are looking at here.  Accounts and passwords, and privilege sets are set up inside the FM file from File > Manage > Security.

Any security settings in the FMS admin console are for accessing the FMS admin console only, not for access to your file.  (With one exception: the configuration option to allow externally authenticated accounts).

 

In short: each user must have their own account.  Each role must have its privilege set.  The privilege set dictates what the user can and can not do in the solution.

 

On FMS, enable the access log.  It's off by default so toggle it on.  It will help you see who logged on and when in case you ever need that information.

[Ian Murphy]

Thanks for both of your responses. I'll briefly answer a few straightforward notes off the top:

 

- the director says we can't afford a server until at least 2015, so I have to make do without.

- FMS writes to a backup folder every 2 hours (in one location) and once a week (in another); Carbonite grabs those backups.

- yes, I access the terminal via RDC. I see you telling me not to. Darn it, but okay.

 

I have downloaded teh Security Guide and I pledge to review it carefully, implementing what I can, before I come back with any more question.

[Wim Decorte]

 

- yes, I access the terminal via RDC. I see you telling me not to. Darn it, but okay.

 

 

I was warning you not to do that for ALL users.  For you as the developer it is ok for certain tasks; but not live development for instance.

[Ian Murphy]

Oh! Got it. No, no one other than me uses RDC.

 

The terminal in question is not a workstation (no keyboard, mouse or screen) - just a black CPU sitting under a switch in a room down the hall. I normally access FMS from within a browser on my own desktop down the hall, but once in a while when I want to work on the terminal in question (reboot it, get a recent file backup, whatever), I use RDC to display it on my screen.