From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer
For most FileMaker solutions, the primary security concern is ...
- keeping the database solution running smoothly
- make sure the data is entered correctly
- make sure it empowers its users to be more productive.
It is quite possible that a security hole can damage the work flow of a database, damage the accuracy of searches & reports and sometimes cause a database to blow up and crash! For example, say that a new user doesn’t really know how to enter information in correctly. So they go to the wrong layout, enter the wrong information in the wrong fields and then the database crashes or the reports are inaccurate.
SECURITY RETURN ON INVESTMENT
Let’s face it, increasing security in a FileMaker solution can become time intensive and sometimes expensive. There is the time it takes to plan, design, implement, document and upkeep a security system. If you skip any of these, your security might be as bad as not having any security at all. There is also the possibility you may need to invest in third party products ( such as plug-ins ) to get the type of security you want.
As we have said before, many FileMaker developers think of security as an after thought, a necessary evil or a type of insurance policy. So it may be helpful to think of what your return is on your investment of securing your FileMaker solution at a particular level. To do this, you may need to identify what business threats are present if your FileMaker solutions security was compromised. This is typically called quantifying risk.
SECURITY POLICIES AND DOCUMENTATION
To most FileMaker developers, there is at least one thing more dreadful than applying security to a FileMaker solution. That would be providing any extensive written documentation about a solution. How important is the documenting the security of a FileMaker solution? A clear policy on what each user can or cannot do with a database solution can be a great aid to a FileMaker developer. Not only in designing or testing the security system of the solution but other productivity related areas as well.
It may help to think of your FileMaker users grouped into individual business units such as sales, marketing, shipping, etc... , which each having a policy of what they can and cannot do within the FileMaker solution. You can also add sub groups to these business units to define security levels by manager, supervisor or data entry person.
A policy also has the benefit of telling your database users what is expected of them.
This can be as helpful as anything a developer can do. If the database or the developer tells a user they should not be somewhere may not carry as much weight as it does in written form coming from their direct supervisor.
While you are at it, you might want to write a policy for the administrators that are in charge of supporting a FileMaker solution. This can be a policy about how the solution can be supported against possible security threats in the future. This can include checking audit logs, sign in logs, user history and other possible security implementations.
We realize this may not be enough information about security policies but do not let that upset you. There are a number of books about the subject which you can find in your local Borders, Barnes & Nobel or at Amazon.com.
More info about the author and FileMaker in general, contact me at firstname.lastname@example.org.
© 2008 - Dwayne Wright - dwaynewright.com
The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.