Chapter 6 | Protecting files 122
Establishing network security
Databases shared on an intranet or the Internet use the TCP/IP protocol. You may also use the
TCP/IP protocol when you share databases peer-to-peer, or with FileMaker
Server. Though
TCP/IP is good for moving data and allowing clients to connect to your data, it was not designed
with security as a primary objective. Unless you take precautions, it can provide uninvited access
to your host computer, server software, databases, and perhaps to other client machines on your
internal network. TCP/IP doesn't provide very much protection for data, so it is important to place
barricades such as firewalls and SSL data encryption in the path of uninvited visitors.
1 The most common barricade method used is the firewall, which separates your network into two
distinct environments: a public environment that is “outside the firewall,” and a private
environment that is “behind the firewall.” Users outside of the firewall will only have access to
those TCP/IP or hardware addresses that you expose. You can concentrate your security on
those server machines that are exposed, while allowing machines behind the firewall to operate
with fewer safeguards.
1 Using wireless networking devices, like the Apple AirPort Extreme and other 802.11n networking
cards and base stations, can pose security challenges. These devices can broadcast your
network traffic beyond the walls of your building, so it is extremely important to encrypt your
wireless networking signals. Always use the maximum level of signal encryption available.
Backing up databases and other important files
Develop plans for restoring data, including alternate sites and systems to run business-critical
information services. A current backup can help you recover from a situation where someone
loses the administrator account information for a file, or from a situation where user error (and
sometimes bad database design) causes data to be deleted or modified inappropriately.
Keep the following points in mind:
1 Host databases with FileMaker Server and create regularly-scheduled, automated backups.
Don’t use third-party backup software on hosted FileMaker Pro databases. First, use
FileMaker
Server to make a backup copy of your database, then run your third-party backup
software on the copy. Backup software can damage open, hosted databases.
For example, make local backups of files at 6:00 am, 9:00 am, 12:00 noon, 3:00 pm, 6:00 pm,
and 11:30 pm weekdays. At midnight, make an incremental backup of the entire system to the
enterprise backup system. Finally, Friday night at midnight, perform a full system backup. Copy
and store the backup tapes at a remote location. This way, if the server goes down for some
reason other than catastrophic failure of multiple drives, the more recent backup of the data files
can be used, meaning a maximum of 3 hours of lost data. If there is a catastrophic drive failure,
then the previous evening’s tape can be used, minimizing the loss to one day’s data. Of course,
these procedures can be tailored to your situation and data value.
1 Make sure backup copies aren’t damaged or inaccessible. Verify that they are functioning properly
before you need them. Run diagnostic tools on your hard drive and your backup files regularly.
1 Ensure that you can restore an entire set of files from backup copies.
1 Regularly export the data to protect against file corruption.
1 Protect the backup media itself. Store backups in a separate and fire-proof location.
1 Assign backup administrators who can retrieve files, in case the network administrator is
unavailable.