Jump to content
  • entries
    44
  • comments
    59
  • views
    88,309

Permissive Versus Restrictive Privileges In FileMaker Pro Databases

Sign in to follow this  
Steven H. Blackwell

1,918 views

Permissive Versus Restrictive Privileges In FileMaker Pro Databases

—By—

Steven H. Blackwell

April 25th 2011

In older versions of FileMaker Pro, those prior to FileMaker® Pro 7, privileges were, by default, permissive. This means that users were allowed to perform all actions by default. With the introduction of the modern versions of the FileMaker Family of Products, with their appropriate focus and attention to industry standards in the security realm, the default privileges became restrictive. This means that databases privileges, especially access to tables and records, are off or restricted by default and have to be specifically enabled for a user’s Privilege Set. Even for the [Full Access] Privilege Set, privileges related to connectivity to hosted files have to be enabled by the developer.

This change began in Version 7 and has continued to the present-day FileMaker® Pro 11 where significant additional protections were added, principally File Access Protection. This is an option that developers may invoke that prevents unauthorized references to a file that could result in data manipulation, script execution, value list item extraction, and Design Function penetrations in ways most developers did not contemplate happening. Additionally, in FileMaker Pro 11, the Available menu commands options setting for a newly created subordinate Privilege Set was changed from Full to Minimum to make that privilege bit’s behavior consistent with all the others. Thus, all privilege bit settings for a newly created subordinate level Privilege Set are either off or set at the most restrictive option.

When FileMaker Pro 7 was released, these changes caused some confusion and even a bit of consternation among both new and experienced users and developers. While much of that has abated over time, it still occasionally surfaces. Yet, I would assert, the present restrictive privilege settings are the correct ones to employ. Why?

A guiding principle of information asset security is the Rule of Least Privileges. That principle holds a user should have all necessary privileges to perform his or her respective role in the database system, but no greater privileges. The FileMaker Pro Role-based Privileges System conforms to this important industry standard principle.

In older versions developers had to try to close all open avenues of access to their database systems. Frequently such actions failed simply because even experienced developers did not know all the “open windows” so to speak. They could close and lock the “front door” and often the “back door” as well. But some windows would be left wide open. This made effective security implementation difficult, threatening both client data and developer intellectual property. The modern-day version of the product closes these wide-open avenues. Now, developers, for the overwhelming part, must explicitly authorize access and privileges. This allows them to protect client’s data and business processes management as well as to secure their own intellectual property.

Preservation of Confidentiality, Integrity, and Availability of digital assets, and sometimes of physical ones as well, is the over-arching purpose of information security in the modern world. FileMaker® Pro 11, the latest iteration of the product, provides more tools and features to accomplish effective security implementation than any prior version of the product. The Rule of Least Privileges is at its best implementation with the current version. I urge developers to employ these security features to their maximum effect.

Steven H. Blackwell

Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use.