Jon Thatcher, FileMaker DevCon 2014
Database encryption is essential for protecting sensitive information stored in FileMaker systems. In this session, Jon Thatcher, the Database Server Lead Engineer at FileMaker, explains the importance of database encryption, how FileMaker implemented it in version 13, and the best practices for working with encrypted databases. This post explores these key insights, diving into the technical details of encryption and performance.
Menu
- Why Database Encryption is Essential
- How FileMaker Server 13 Implements Encryption
- How FileMaker’s AES-256 Encryption Works
- Performance Impact of Encryption
- Password Handling and Best Practices
- Keystore and Encryption Management
- Recovering and Backing Up Encrypted Files
- Best Practices for Encrypting Databases
- Key Takeaways from the Session
Why Database Encryption is Essential #tag1
In today’s digital landscape, data protection is more important than ever. Database encryption ensures that sensitive information stored in FileMaker systems is secure, even if unauthorized individuals gain access to the physical server or backup files. Encryption is especially crucial for businesses dealing with:
- Financial data: Banks, accounting firms, and investment companies need to ensure that customer financial information is protected at all times.
- Healthcare data: Medical organizations are required to protect patient data under regulations like HIPAA.
- Legal data: Law firms must ensure that client data remains confidential.
While SSL encryption has long been used to protect data in transit between the client and server, it only secures data while it’s being transmitted. Before FileMaker 13, data stored on the server or backups was vulnerable. Database Encryption at Rest (EAR) introduced in FileMaker 13 addresses this vulnerability by encrypting the data stored in the database.
How FileMaker Server 13 Implements Encryption #tag2
FileMaker 13 introduced Encryption at Rest (EAR), which uses the AES-256 encryption standard to protect data stored within the database file itself. When you enable encryption, every block of data in the database file is encrypted, ensuring that sensitive information cannot be accessed without the encryption password.
How Database Encryption Works:
- AES-256 Algorithm: The Advanced Encryption Standard (AES) with a 256-bit key length is used to encrypt the database. AES-256 is widely regarded as one of the strongest encryption algorithms, and its use ensures that even if someone gains access to your physical database file, they cannot read the data without the decryption key.
- Block-Level Encryption: Every 4KB block of data in the database is encrypted. Each block is decrypted only when it is read from the disk into FileMaker’s RAM. When data is written back to disk, it is re-encrypted.
- Encryption of Temporary Files: In addition to encrypting the main database, FileMaker also encrypts temporary files and server backups. This ensures that all parts of the system remain secure, even when data is temporarily stored on the server during processing.
The encryption password must be entered when the file is opened, either by FileMaker Server or FileMaker Pro. If the password is lost, the data is irretrievable.
How FileMaker’s AES-256 Encryption Works #tag3
AES-256 encryption, used in FileMaker, is a robust encryption algorithm that is highly resistant to brute-force attacks. Jon Thatcher provided detailed insights into how the algorithm works and how FileMaker applies it to secure database files.
Key Features of AES-256 Encryption
- Block-Based Encryption: FileMaker divides the database into blocks, with each 4K block being encrypted using AES-256. This block-based approach ensures that only small sections of the file are decrypted at a time, reducing the exposure of data.
- Unique Salt for Each Database: Each database has a unique salt value, which is combined with the password to generate the encryption key. This prevents attackers from using precomputed tables (rainbow tables) to guess the encryption key.
- Random Data for Extra Security: Each block of data includes additional random data, ensuring that even if two blocks contain the same information, they will be encrypted differently. This makes it impossible for attackers to recognize patterns or infer information based on block similarity.
- Encrypted Checksum: Every block contains an encrypted checksum, which is used to verify the integrity of the data when it is decrypted. If the checksum doesn’t match, the data is considered corrupt, and the block is discarded.
This combination of encryption, salt, and checksums ensures that the FileMaker database remains secure, even if an attacker gains access to the raw file.
Performance Impact of Encryption #tag4
While encryption adds a layer of security, it also introduces some overhead. Jon Thatcher explained that the goal for FileMaker Server 13’s encryption feature was to keep the performance impact as minimal as possible—below 10% in most cases.
Impact on File Reads and Writes
- Writing Data: When data is written to disk, the 4K block is encrypted before being saved. This adds a small amount of time, but the overhead is minimized because modern CPUs (such as those using Intel’s AES-NI instruction set) can perform encryption operations efficiently.
- Reading Data: When data is read from disk, it is decrypted by the Draco engine as it is loaded into memory. Again, this adds some overhead, but FileMaker’s caching mechanisms help reduce the frequency of disk reads and writes.
Performance Results
Jon Thatcher shared performance results showing that the encryption feature added around 5.5% overhead when using a local file and 2% overhead when using the “Perform Script on Server” feature. The file size also increased by approximately 1% due to the inclusion of random data and checksums.
Despite the performance impact, the added security of encryption makes it a worthwhile trade-off for most businesses, especially those handling sensitive data.
Best Practices for Managing Encrypted Databases #tag5
Encrypting your FileMaker database adds a strong layer of security, but it also introduces new considerations for database management. Jon Thatcher provided several best practices to ensure smooth operations and avoid potential pitfalls.
1. Use Strong Passwords
The security of your encrypted database is only as strong as the password used to encrypt it. Thatcher recommended using strong, complex passwords with at least 10 characters, a mix of upper and lowercase letters, numbers, and symbols.
2. Securely Store Encryption Passwords
FileMaker, Inc. cannot retrieve your encryption password if it is lost. Thatcher stressed the importance of storing encryption passwords in a secure location, such as a fire-proof safe or a bank deposit box. Losing the encryption password means losing access to the data permanently.
3. Avoid Saving as Compacted Copy Before Encryption
Before encrypting a database, avoid using the Save as Compacted Copy feature, as it fills each 4K block up to 100%. Encrypting a compacted file is much slower since FileMaker must first “uncompact” the file. Thatcher recommended only compacting the database after encryption has been applied.
4. Use Server Keystore for Encryption Passwords
FileMaker Server provides an optional keystore feature for securely storing encryption passwords. If enabled, the keystore stores passwords per database, preventing the need for administrators to enter the password every time the server restarts. The keystore itself is encrypted with machine- and user-specific data, ensuring that it cannot be decrypted on another system.
How Encryption Affects Backups and Recovery #tag6
One of the most significant concerns for businesses using database encryption is how it affects backups and recovery operations. Jon Thatcher explained that FileMaker Server 13 handles encrypted databases with minimal impact on regular operations.
Backups
- Scheduled Backups: FileMaker Server performs block-for-block backups of encrypted databases, meaning that no decryption or re-encryption is necessary during the backup process. This ensures that the backup is an exact copy of the encrypted database, with no AES overhead.
- Progressive Backups: Progressive backups, which save incremental changes, do have some overhead when working with encrypted databases. Each change must be recorded as a full 4K block, rather than a smaller set of bytes as in unencrypted databases. This results in slightly larger and slower progressive backups.
Recovery
- Database Recovery: If an encrypted database becomes corrupted, FileMaker’s recovery process requires the encryption password to decrypt each 4K block before validation. Any blocks that fail validation are discarded, and valid blocks are re-encrypted with new salt values before being written to the recovered file.
- Save a Copy: Using the Save a Copy feature re-encrypts the entire database with new salt values, ensuring that the copy is a logical duplicate, not a byte-for-byte duplicate.
By understanding how encryption impacts backups and recovery, administrators can ensure that their databases remain secure and can be restored without data loss.
Security Considerations and Encryption Password Management #tag7
Managing encryption passwords is one of the most important aspects of working with encrypted FileMaker databases. Jon Thatcher outlined several security considerations that businesses must take into account to ensure the safety of their encrypted files.
1. Password Security
- Use Strong Passwords: A strong password is your first line of defense against unauthorized access. Thatcher recommended using complex passwords and avoiding dictionary words or easily guessable combinations.
- Change Passwords Regularly: It’s important to change encryption passwords periodically, especially if there is any suspicion that the password may have been compromised.
2. Storing Passwords Safely
Encryption passwords should be stored in a highly secure physical location, such as a fireproof safe or a safety deposit box. As Jon Thatcher emphasized, FileMaker cannot recover lost passwords. If the password is lost or forgotten, the encrypted database cannot be decrypted, rendering the data inaccessible.
3. Using the FileMaker Server Keystore
FileMaker Server 13 introduced an optional keystore for securely managing encryption passwords. This keystore can store the encryption password used to open the database so that administrators don’t have to manually enter it every time the server starts. Here’s how the keystore works:
- Machine-Specific Security: The keystore is encrypted using machine- and user-specific data, making it impossible to copy the keystore to another server and decrypt it.
- Password Management: Administrators can choose to store the encryption password in the keystore only at the time the database is opened. The keystore can also be cleared at any time if the administrator wants to remove stored passwords.
- Secure Access: The keystore is only accessed by FileMaker Server when the encrypted database is opened, minimizing potential vulnerabilities.
4. Multi-File Solutions and Shared IDs
For multi-file solutions, FileMaker allows the use of a Shared ID to group files with the same encryption password. This feature enables a single password entry when opening a solution with multiple encrypted files, streamlining access and reducing the administrative burden.
- Shared ID Management: Although the files use a Shared ID, each file in the solution can still have a different encryption password. The Shared ID simply instructs FileMaker to try the first encryption password across all files when opening them.
- Caution with Shared IDs: Administrators should carefully manage Shared IDs to ensure that multi-file solutions are properly secured and that the same Shared ID is used when adding new files to the solution.
By following these best practices for password management and leveraging the FileMaker Server keystore, businesses can secure their encrypted databases while ensuring ease of access for administrators.
How Encryption Affects Backups and Recovery (Continued) #tag6
Backup Strategies for Encrypted Databases
Backup strategies remain largely unaffected by encryption, thanks to FileMaker’s block-for-block copy method, which avoids the need to decrypt the database during backups. However, there are some important considerations for optimizing backups with encrypted databases.
- Scheduled Backups: As noted earlier, scheduled backups of encrypted databases are performed without decryption or re-encryption, making the process efficient. However, it’s important to ensure that backup schedules are frequent enough to protect against data loss in the event of a hardware failure or disaster.
- Offsite Backups: Offsite backups should always be encrypted. Storing backups at a remote location can protect against physical disasters, such as fires or floods. By encrypting the backup files, you ensure that the data remains protected even if the backup media is stolen or misplaced.
Progressive Backups for Encrypted Databases
Progressive backups, which track changes to the database in near real-time, are affected by encryption. Since each change must be written as a full 4K encrypted block, the progressive backup logs are larger compared to unencrypted databases. This can lead to increased storage requirements and slightly longer backup times.
- Optimizing Progressive Backups: To minimize storage and performance overhead, administrators should monitor the size of progressive backup logs and adjust backup frequencies based on database activity levels.
Database Recovery with Encryption
In the event of database corruption, recovery operations for encrypted databases require the encryption password to decrypt and validate each block. During recovery:
- Block Validation: Each 4K block is decrypted and checked against its checksum to verify data integrity. If a block is damaged or cannot be decrypted, it is discarded.
- Re-Encryption During Recovery: Valid blocks are re-encrypted with new salt values during recovery, ensuring that the recovered file is fully secured with fresh encryption keys.
It’s important to note that recovery operations are slower for encrypted databases, as every block must be decrypted before validation. Administrators should plan for additional time when recovering large encrypted files.
Key Takeaways from the Session #tag8
Jon Thatcher’s session provided deep insights into FileMaker Server 13’s database encryption feature and its implications for security and performance. Here are the key takeaways:
- AES-256 Encryption at Rest (EAR) provides robust security for sensitive data, ensuring that even if a database file is stolen, the data remains inaccessible without the decryption password.
- FileMaker Server’s Encryption Implementation: FileMaker encrypts each 4K block of data, adding random data and encrypted checksums to prevent attackers from inferring information from the encrypted file. Every block is decrypted as it is read into memory and re-encrypted when written back to disk.
- Password Management: A strong encryption password is critical, and businesses must ensure that passwords are securely stored. FileMaker’s optional keystore provides an efficient way to manage encryption passwords for server environments.
- Performance Impact: The encryption feature has a minimal impact on performance, typically adding less than 10% overhead during normal operations. However, progressive backups and recovery processes do experience additional overhead when working with encrypted databases.
- Backups and Recovery: Backups of encrypted databases are efficient, thanks to FileMaker’s block-for-block copy method. Recovery operations, however, are more time-consuming due to the need for block-by-block decryption and re-encryption.
- Security Best Practices: To maximize the benefits of encryption, administrators should follow best practices such as using strong passwords, securing the keystore, avoiding compacting files before encryption, and performing regular audits of access controls.
By implementing these best practices and understanding the impact of encryption on performance and backups, FileMaker users can ensure that their data is well-protected while maintaining efficient operations.
This comprehensive blog post covers Jon Thatcher’s session on database encryption in FileMaker Server 13, offering in-depth insights into how the encryption feature works, its impact on performance and backups, and best practices for managing encrypted databases. By leveraging FileMaker’s encryption tools, businesses can safeguard their sensitive data and comply with industry regulations while maintaining the integrity and availability of their databases.
DevCon 2014: Under the Hood with Database Encryption and FileMaker Server 13 – Jon Thatcher
