Architecture and Security in FileMaker

Overview


DayBack is a web viewer in FileMaker, meaning its application code is hosted on DayBack's servers at dayback.com rather than within your FileMaker file. This allows for frequent updates without the need for customers to modify FileMaker scripts. When bug fixes and new features are pushed to the server, customers benefit from them immediately.

Because of this setup, some application settings are also stored on DayBack's servers. This document outlines the division of labor between DayBack and FileMaker, detailing which information is stored where.

Details

Security review

DayBack has successfully passed the rigorous security review required for all AppExchange apps. This review includes testing DayBack's servers, conducting penetration tests, checking for injection vulnerabilities, and examining all traffic between dayback.com and Salesforce.

Where is my event data stored?

Throughout the remainder of this document, the term "event" refers to any FileMaker record displayed on the DayBack calendar, such as an appointment. This could include records from any FileMaker table you have chosen to show on the calendar.

  • No Event Storage: Events are stored only in FileMaker and do not pass through DayBack's servers when displayed on the calendar.
  • In-File Data Query: DayBack uses FileMaker scripts to search for and retrieve information about which events to display. This is all done with your file.
  • No Shadow Tables: DayBack does not maintain an event database or shadow tables on its servers.

Does DayBack respect our FileMaker Access Privileges?

Yes. The FileMaker scripts that DayBack runs are run as the logged-in user. Therefore, a DayBack user has no more and no less access to their FileMaker data than they do on other FileMaker layouts.

What is stored on DayBack's servers?

DayBack records your calendar settings on its own servers. This includes all the information in the "admin" side of DayBack:

  • Calendar Sources: Information on the calendar sources you use, as shown above.
  • Admin Settings & Defaults: Settings from the "Admin Settings & Defaults" section of the DayBack admin screen, such as default view, time increments, start time, etc.
  • Status and Resource Names: Names of your statuses, resources, resource folder names, and status colors.
  • Custom Actions: If you've created custom actions to customize DayBack, the code for those actions is stored on DayBack's servers.
  • User Information: DayBack records the email address of each FileMaker user authorized to use DayBack. This is the information you enter when you invite a new user to DayBack as shown below:

Here's a diagram of how data moves between FileMaker, the user's browser (FileMaker web viewer), and DayBack's servers:

This data is backed up daily and retained for 30 days.

What about sharing?

The sharing feature in DayBack is specifically designed to publish calendar data to people who don't have access to your FileMaker file. You can turn this capability off or restrict it to certain users. Event data can only leave FileMaker when you manually create a public bookmark. For details on how this works and what data is actually published, see sharing.

Sharing is similar to exporting your event data. A share recipient has no access to your FileMaker file. Bookmarks "shared" with "just me" or "my group" do not leave FileMaker; only public bookmarks allow data to be accessed outside of your file.

Infrastructure

Where are DayBack's servers?

DayBack's storage is hosted on a Firebase Cloud Firestore server in the United States. You can learn more about Firebase locations here. During DayBack's security review with Salesforce, the team thoroughly inspected all traffic between DayBack and the server to ensure it was secure, using WSS (secured web sockets).

Our application itself is hosted on Digital Ocean's servers, using region-based load balancing. The servers are located in San Francisco US, London England, and Sydney Australia. Users will connect to the server located closest to their location or based on server availability.

Encryption

Data is encrypted at rest and in transit.

Data at Rest:

  • Data is encrypted with server-side encryption.
  • Firebase manages cryptographic keys using the same robust key management systems that Google uses for its own encrypted data, including strict key access controls and auditing.
  • Each Firestore object's data and metadata are encrypted under the 256-bit Advanced Encryption Standard.
  • Encryption keys are themselves encrypted with a regularly rotated set of master keys.

Data in Transit:

  • We use Transport Layer Security (TLS) for data in transit.

Datacenter certifications

Firebase Cloud Firestore:

  • Successfully completed ISO 27001, ISO 27017, and ISO 27018 evaluations.
  • Also compliant with SOC 1, SOC 2, and SOC 3. More details can be found here.

DigitalOcean:

  • Certified in the international standard ISO/IEC 27001:2013. DigitalOcean is AICPA SOC 2 Type II and SOC 3 Type II certified.  More details can be found here.

Related Articles