MIT Libraries Policy on the Use of FileMaker for Applications
November, 2006
Background
Desktop computer applications like FileMaker, Microsoft Access, Microsoft Excel,
etc. are useful for building small-scale departmental systems easily, but there are
problems with their security, interoperability, reliability and scalability. This
document provides guidelines for when it is appropriate to use FileMaker or
Access for computer applications and when another technology platform is called
for1. The main areas of concern for FileMaker (but equally applicable to Access
or Excel) are listed below.
1. Security
As with any software manufacturer, FileMaker Inc makes no guarantees
about the security of their product. The following outlines the risks, which
apply not only to FileMaker but to any local database development
environment2.
Novice database designer
• High risk of unintentional threats caused by employees having
inappropriate file and database feature access.
• Employees may introduce unintentional threats by sharing files without
taking proper security measures.
• Data is exposed if FileMaker Pro accounts and privileges are not
configured correctly to protect files adequately.
Inexperienced system administrator
• High risk of unintentional threats caused by inadequate operating system
security, poor backup techniques.
• Poor network security increases the risk of intentional threats, particularly
if files are shared over the web or on a wireless network.
• Risks are also introduced if shared files are accessed from file servers
instead of using the built-in network sharing in FileMaker Pro and FileMaker
Server. Employees can make inappropriate copies of the files and can
introduce record locking and potential corruption issues when files are
shared with inappropriate methods.
Databases store sensitive or valuable data
1
The standard alternative to using FileMaker or Access for a database application is the LAMP platform:
Linux, Apache, MySQL, and PHP (or Perl). We will also support PostgreSQL, and Oracle databases.
2
Source-http://www.filemaker.com/downloads/documentation/fm8_security.pdf
Page 1
Increased risk of intentional threats of data theft, particularly if data is
shared over the web or if access to data isn’t adequately monitored and
protected.
2. Integration
FileMaker provides limited ODBC and JDBC integration to the application.
Specifically, it is not fully SQL compliant, which can make it difficult to
create automated access to FileMaker data from other systems. For more
information see
http://www.filemaker.com/downloads/documentation/fm8_odbc_jdbc_developer.
pdf
3. Scalability
FileMaker is not suitable for large-scale applications (i.e. more than
100,000 records, more than 50 concurrent users for write operations or
100 users for read operations, more than 20 db tables or single tables
with more than 100 fields).
4. Reliability
In the event of a server failure such as an unexpected loss of power, hard
drive failure, or software failure, it will be necessary to restore the entire
application from backup files. Any system failure causing FileMaker Server
to shut down inappropriately can result in corrupted files if cached data
was not written to disk and the files were not closed properly (i.e. full
ACID compliance). Even if the files re-open and go through a consistency
check or recovery, corruption might be buried in the file. File recovery
cannot guarantee that problems have been fixed.
Page 2
Policy Statement
The Libraries recognize the need for developing applications with an easy-tolearn-and-use tool such as FileMaker. In an effort to gain the benefits of common
knowledge and experience, we recommend that FileMaker be used for
applications that meet the following criteria:








It’s a local application used within a single department or unit.
There will be fewer than 50 users of the system at any time.
It’s not used to develop applications that are expected to evolve
into a complex database. Measures of complexity to consider are:
o There are more than 20 well modeled tables or files
o The application costs more than $30k to develop.
o Tables have a field count exceeding 100.
There is no sensitive data being stored that will be distributed by
the application via the Web or email etc. (for a definition of
sensitive data, see http://istwiki.mit.edu/istwiki/ItagSensitiveData).
o Examples of data that should never be stored in FileMaker
are: personal information such as medical, SSN, or credit
card information.
The current recommended FileMaker version and server/client
configuration are used.
http://itinfo.mit.edu/product.php?name=filemaker
The application will have little need to integrate with other
applications, except accessing information from the Warehouse.
The data collected will not need to be accessed by other nonFileMaker systems, such as the SFX/Metalib, Barton, or the MIT
Data Warehouse.
It isn’t a System of Record for any Libraries enterprise data.
Note: If you need help interpreting these guidelines, please contact STS.
Page 3
Best Practices for Use of FileMaker
All recommended measures are being followed. Examples:
 Use FileMaker Server and not a peer-to-peer configuration
 Use strong passwords
 Hide filenames from network scanning on port 5003
 Turn on SSL
 Implement a robust backup and recovery procedure
 Physically secure your server and backup media
 Store backup media in alternative locations
 If feasible, use a Server OS firewall
See additional guidelines on using FileMaker at
http://web.mit.edu/ist/help/filemaker/fmug/Top10.pdf
See also more detailed information at http://web.mit.edu/ist/db/fm/
Page 4