TotalRoute.net can host your FileMaker Pro version 5, 5.5, 6, 7 or 8 databases for you for a very reasonable cost. We have multiple FileMaker Servers for optimum response from your databases.
FileMaker Pro: Security Guidelines
On this page: The Issue | Example | Secure FileMaker Sites | The Future | Afterword
--------------------------------------------------------------------------------
The Issue
FileMaker products allow you to share data over the network and via the Web. It is very important, therefore, that FileMaker developers ensure their solutions meet minimal security requirements for shared data sources at MIT. Please be sure to review the Security Guidelines below carefully, before deploying a FileMaker database at MIT.
Note: If you are looking to create an enterprise-wide solution, or one that requires very high security, FileMaker may not be the most appropriate software for your needs. You might want to explore enterprise-level database management solutions (e.g., Oracle, for which MIT has a site license).
Although FileMaker software is supported and even recommended for a variety of purposes at MIT, many FileMaker sites on campus make little or no provisions to safeguard the data they store. Partly this is a limitation in the software (currently, FileMaker does not meet MIT's high standards for Kerberos-based authentication or encrypted data transmission), but often it is simply a result of neglect or ignorance. FileMaker, Inc. is working to provide a solution, however currently FileMaker provides no real security unless you deliberately put it in.
--------------------------------------------------------------------------------
Example
Take an unfortunately common example: a good number of databases created at MIT do not require passwords.
This is all the more remarkable because often the data being stored is sensitive Institute data (including local department data). Although the initial source of the data may have been highly-protected MIT data, it is not uncommon to find a downloaded copy of this data available on a network-shared FileMaker database with no password.
Apart from being a violation of MIT policy (Institute data -- including locally gathered data -- needs to be protected), it is also poor data management and opens departments and the Institute as a whole to more widespread dangers. Suppose, for instance, that a poorly protected FileMaker database contains password information for other MIT services (e-mail passwords, for instance). By getting into that FileMaker database, a hacker would then have the information needed to hack other MIT services, including personnel records and financial data. Maybe the hacker wouldn't even have to go that far -- maybe the database itself has everything the hacker wants to know.
--------------------------------------------------------------------------------
Secure FileMaker Sites
What can you do to secure your FileMaker sites?
Always Require Passwords For Your Databases
Just this step will vastly improve the security of your system against the most common threats. However, adding passwords can be a little harder than it sounds. FileMaker's security schemes are somewhat esoteric. For instance, FileMaker's passwords are not inherently tied to individual users; instead, passwords link up more with "groups" that the database designer can define. For the Web, a separate security system is also available.
The awkwardness of FileMaker's password scheme, or the need to administer a large number of passwords and associated privileges, can lead some database developers to work around FileMaker's system and instead create their own table-based username/password "login" scheme. In general, this can be useful in adding features to a database system -- but it usually does not create any additional security, and may even mask security problems left unresolved. In any case, if you choose to introduce a table-based "login system" to your solution, do not base this on blank passwords or auto-entered passwords; the database would be too vulnerable to reasonably experienced FileMaker hackers.
Be Aware That Shared FileMaker Data is Sent "In the Clear," Unencrypted and Unencoded
If you share sensitive data in your database (and even if you don't share the data), you should consider ways to store data in an encrypted form -- and only let the data be decrypted when it has gotten to its destination. In fact, for certain data (e.g., student information), MIT is required by law not to send the data over the network in the clear.
Useful FileMaker plug-ins to consider for encryption include the Coding plug-in offered by Troi Automatisering, or the Crypto Toolbox plug-in offered by Protolight Software.
For highly sensitive data, you may need to avoid sharing the data over the network altogether. If you still need to share the data, you may decide that FileMaker is simply not the correct product for your needs. Oracle is MIT's site-licensed recommendation, involving a larger resource investment than FileMaker.
Be Aware that FileMaker Passwords Are Not Really Secure; Never Use MIT Kerberos/E-mail Passwords for FileMaker Passwords
To authenticate users in multi-user settings, FileMaker software uses a security scheme developed several years ago, before the potential (now actual) vulnerabilities of the Internet were well understood. For instance, FileMaker's scheme involves sending all the database passwords from the server to the client across the network in order to confirm a user-entered password. (In contrast, many modern security schemes, such as MIT's Kerberos system, are able to authenticate users without ever needing to send any passwords across the network in any form.) FileMaker's scheme makes it possible for hackers to capture the set of passwords as they are sent over the network.
Fortunately, FileMaker's passwords are at least "encoded" -- unlike the field data, the passwords are stored and transmitted in an encrypted form, not "in the clear." Unfortunately, the encryption method used is extremely weak by today's standards. Consequently, FileMaker's passwords are not really secure: sufficiently advanced hackers can potentially tap the line, capture the encoded passwords, then decrypt all the captured passwords. Of course, it isn't easy, but it can be done. Needless to say, MIT's network is constantly being assailed by "sufficently advanced hackers" -- so this is a genuine threat. (It should be noted that FileMaker is not alone in continuing to use inadequate security schemes. Some other software in use at MIT also suffers from this problem. See the Afterword below.)
In any case, FileMaker passwords are much more vulnerable than Kerberos passwords. Since FileMaker's vulnerability is greater than MIT's central services, it's important to retain the integrity of users' Kerberos identities by keeping FileMaker passwords distinct from Kerberos passwords.
Ensure the Physical Security of Your Databases
Even if you do not share your FileMaker databases (e.g., you always work in single-user mode with a database on your office computer, or you have the databases on a diskette or portable computer), those databases are only as safe as the machine they are on -- especially if they are not protected by passwords. If someone can get to your password-less databases (get into your office, steal your laptop, etc.), they can get to your data.
Be Especially Careful to Consider Security Via the Web
If you serve your databases via the Web, or intend to, be aware that your data is especially vulnerable to inappropriate access. Web servers are designed to give people access to data, not to keep them out, and FileMaker's Web Companion is no different. If you don't take steps to protect your data with password/access protection -- and additional protections -- FileMaker will not hesitate to give your data away to anyone who asks for it.
Even database developers who set up a database appropriately for network sharing (using passwords, etc.) often don't realize that the same database needs extra protection when opened to the Web. For example, a typical mistake is to place the database itself in FileMaker's Web directory along with the HTML interface files -- this allows people to download the database directly. A more elusive point is that FileMaker's Web server has known holes that the standard FileMaker password system does not protect against (especially regarding fields in related databases).
Another important point to realize when designing security for databases served via the Web is that Web users are not limited only to the transactions you specifically design into your Web pages. For example, if you create a link that uses an option like "name=Smith" in the URL to carefully point users to a specific set of records (Smith's data), there's nothing to prevent those users from editing the URL in a browser to say "name=Jones" or "name=Chen" so that they can see data you did not expect them to look at. If you know of this vulnerability, you may decide to use CDML pre-processor tags in your HTML documents to hide some of the details of the selection criteria you are using (i.e., keep it out of the highly visible URL), but savvy users can just peek at the source of your HTML and see what you're doing. (The "name=Jones" example might be addressed by the next point below -- record-level access control -- but the general point is still true: web users can edit the URLs and potentially access different information than you thought they might.)
Using FileMaker in multi-user ("peer-to-peer") mode at least has the advantage of obscurity -- it's not likely that a random hacker will chance across a database they didn't already know existed. Once you begin serving data via the Web, however, the whole world can quickly become aware of your data and can proceed to exploit inadequacies in your security design.
For additional guidelines regarding security when using FileMaker on the web, be sure to read FileMaker Inc.'s white paper on this topic -- FileMaker Pro Web Publishing Security Guidelines and its associated FAQ [Adobe Acrobat required].
Consider Using FileMaker's "Record-by-Record Access Privileges" Feature But Understand its Limitations
FileMaker Pro 5.5 allows data access control for individual records. You can now specify calculation formulae to restrict browsing, editing, or deleting individual records, based on the user’s password. For example, an administrator-level password can be given privileges to access the records of all students in every professor's class, while a professor-specific password might limit the user to browsing the student records associated with courses that only that professor teaches. (Fortunately, unlike certain other FileMaker password privilege settings, this feature does carry over to databases published on the Web.)
Be careful implementing record-level access control. For example, it is possible to restrict "browse" access to specific records but leave "delete" access for all records -- you could have a situation where a user can't see the data in a record, but can blow away the whole record. This is not a limitation of the feature: like any powerful tool, it can be misapplied. Developers should take care to understand the implications of what they're doing when implementing record-level access control.
There are also some unexpected behaviors to take into account, not related to security. For example, you might expect that if a user does a Find on some criterion, the found set would exclude any records the user does not have privileges to view. This isn't the case: the record is included -- the data is just not visible. If you did a CurrentFoundCount to produce some statistic in this case, it might be misleading. Developers will need to consider these kinds of oddities in constructing robust solutions where record-level access control is used.
One final point that might help clarify how MIT database developers should look at this new feature: FileMaker calls this feature "Record-Level Security", but in our environment, it might better be thought of as simply "Record-Level Access Control". Although a valuable way of protecting data, access control in itself does not include all the features that the word "security" might imply to a developer here at MIT. Perhaps that distinction will help set expectations appropriately.
--------------------------------------------------------------------------------
The Future
It is possible (though unlikely) that FileMaker Inc. will build enhanced security (e.g., encryption) directly into future versions of the FileMaker software. It is very unlikely that Kerberos-based authentication will ever be part of FileMaker's approach to security. So, currently, we are left to fend for ourselves and piece together approaches to securing our databases using a variety of methods and tools.
It could be that an appropriate long-term solution to many of FileMaker's security limitations (i.e., the password/encryption deficiencies noted in points 1, 2, and 4, above) may involve sharing databases only via the Web using an SSL-supporting Web server. FileMaker 5.x and later versions allow this kind of setup. Data could then be encrypted by the Web server during transmission and users could identify themselves via Web-based certificates. The databases would have to be designed to work with the certificate information being provided by the Web server. Other limitations of FileMaker's built-in security could be addressed using various features of the secure Web server. Even in this scenario, however, database designers will still need to carefully consider the limitations of FileMaker's Web access (point 5 above) and address those concerns as well.
MIT Information Services and Technology is exploring this and other scenarios and will propose recommendations for the MIT community as they are tested and validated.
Whatever the future, it seems that a good deal of work will still be involved in working around the security limitations of FileMaker in the MIT environment.
--------------------------------------------------------------------------------
Afterword
FileMaker is not alone in being vulnerable in terms of security. E-mail programs such as Eudora and even MIT's data backup program, Tivoli Storage Manager (TSM), pass their data in the clear. Other data systems on campus have remarkably lax security (physically accessible machines, data stores with no passwords, etc.).
Regardless, it is important that FileMaker developers on campus take steps to make sure that their databases are secure to the extent possible, and to encourage others to do likewise.
|
