Your Security Plan - File Maker

Before you create even one database with one field, you should have a security plan. Every database developer worries about the security of his or her database system, and a plan will help you put down everything you need to worry about on paper. Interview your users or your client. Make sure you’ve covered all the bases.

Following is a list of topic areas and questions you should answer in your security plan, along with some suggested answers.

Physical Security
In order to minimize risk of data loss through damage or theft, take care to restrict access to the physical hardware and software that store and distribute your database system in the following areas:

Server PC
The database system will be served from a particular workstation or server. Make sure that this computer cannot be tampered with by unauthorized persons by locking it in a room. You might also consider locking the computer itself down with a chain. Also, consider making the server headless — i.e., it has no monitor so that it can only be securely administered remotely (though remote administration software adds its own security risks). Your database server should log idle users off after a certain amount of time.

Network
Make sure that only authorized persons have network access to the server hosting the databases. No one else should be allowed to log in, via regular network protocols or via remote access software. If they do, they could gain access to your databases. Included in this section are issues of setting up a firewall to keep intruders out, making sure that “packet sniffers” can’t grab FileMaker data out of the ether on its way back and forth from server to client (and vice versa), and making sure that there are no insecure access points to your network (unused offices in your building with live Ethernet cables coming out of the wall).

User PC
For every workstation that can access the database, make sure that proper security is in place to prevent unwanted access to the database. This includes requiring users to log on to a workstation before allowing them to do anything on it, and timing out a user after five to ten minutes of activity to minimize the risk of someone coming to someone else’s workstation and accessing the database.

Modems/Internet Access
Make sure that there are no always-on Internet connections to the database’s server (or to PCs that can access the server) without first making sure that those connections are properly secured behind firewall hardware or software and usage logs.

Database System Security
Determine who can access the database system and how much access any given type of user has in the system.

Passwords
All databases should have passwords associated with them. Users should be required to enter a password and user name to access the database system.

  • Different passwords should allow different access. Administrators should have their own passwords, and each user should have their own. You should come up with a plan for what access levels you will need and how they are defined. For instance, can some users “read only” but not add records?
  • Should only one person have rights to create new user accounts? Who should be allowed to see financial or employee records? Who should be allowed to delete records? Export records? Print certain reports? Who should be able to press the “Underprice Our Competitors” button?

  • Users should be required to use passwords and user names that are hard to guess. Logic should be built to not allow passwords to repeat over time or be too simple. For example, require a password to be at least seven characters long and contain at least one number. Passwords should occasionally expire and require changing, and require knowledge of the old password to create a new one. Users should get reminders about their soon-to-be-expired password seven days in advance. Users should be locked out after three failed attempts to log on. All database system logins and logouts should be logged in an audit log database.
  • Passwords should be encrypted whenever possible.
  • Administrators should have the ability to reset or change users’ passwords when necessary. They should also be able to deactivate users when necessary.

Audit Log
If necessary, you should design the system such that any change to any field in any record in any database is logged. By reviewing the log, you should be able to see what the original value was, what the new value is, where the change was made (what database or field), when (date and time), by whom (which user), and perhaps in what environment (platform, version of FileMaker, on what layout, and so on).

Backing Up
Come up with a regular, scheduled backup scheme so that you always have other copies of the database to fall back on should the main system fail.

Regular Review
On a semi-regular basis, depending on your work environment, you should review your security plan and, in light of any recent developments within your organization, change the security features of your database system.

Emergency Plan
Come up with a step-by-step protocol to use in case of various emergencies (crash, disgruntled employee, corrupted database, tsunami, and so on).

Known Risks
Write down a list of any known risks and try to come up with ways to eliminate or mitigate them so that they don’t become emergencies or security breaches.

User Training
Carefully train any user who will access the database system to properly access it and know all of its security features as well as the general security policies of your organization, like how to create passwords or how to log on and off of the network safely.

FileMaker Pro Security
In a few moments, we’ll examine all of the features built-in to the FileMaker Pro application, which you can use when building databases. But, before building anything, you should ask yourself:

  • Who should have access to each database?
  • Who should be allowed to browse records? Create them? Delete them? Export them?
  • Who should be able to access the user’s database or create new user accounts?
  • Who should be allowed to see sensitive financial figures?
  • Who should be allowed to even log in?
  • Who should be allowed to run certain reports or go to certain databases or layouts?
  • Who should be able to see data in certain records? Can one person see another person’s records? If so, under what conditions?

Knowing all of this will help you organize the proper mélange of FileMaker security features so nothing nefarious happens to your database system. You’ll learn about all of these built-in features shortly.

Additional Security
In addition to FileMaker’s built-in security, you may choose to add additional security to your databases in the form of additional software, such as the SecureFM, Troi Coding, or DialogMagic Plug-ins. Also, you may choose to administer passwords for your solutions using a tool like New Millennium’s Password Administrator suite (a great little tool). You’ll learn the ins and outs of these add-ons later, but as you write your security plan, you should consider these additional pieces of software and see if there’s something that you simply have to have.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

File Maker Topics