Architecture and Security in Salesforce
Overview
DayBack is a Canvas App in Salesforce which means the application code is not inside your Salesforce pages but is instead hosted on DayBack's application servers at dayback.com This means DayBack can be updated very frequently and without the need for customers to install new packages: bug fixes and new features are pushed to the server and customers can take advantage of them right away.
This means that some of the application settings are also stored on DayBack's servers and this document describes the division of labor between DayBack and Salesforce and which information is stored where.
Details
Security review
DayBack passed the thorough security review required of all AppExchange apps. In the case of Canvas Apps, this review also includes testing DayBack's servers, penetration testing, and probing DayBack's configuration for injection vulnerabilities, and examining all traffic between dayback.com and Salesforce.
Where is my event data stored?
In everything that follows, we'll use the word "event" to mean any Salesforce record showing on DayBack calendar: like an appointment. This could be a record from the native Event object in Salesforce, a Task or a Campaign, or a record from any custom object you've elected to show on the calendar.
Events are only stored in Salesforce and don't pass through DayBack's servers on the way to being displayed on the calendar. DayBack uses the REST API via the Canvas SDK to query Salesforce and this is all done inside your Salesforce pages. DayBack doesn't have an event database of its own or a shadow table on DayBack's servers.
Does DayBack respect our profiles and role hierarchy?
Yes. The REST API runs under the authentication of your logged in user, using the Signed Request authentication flow provided by the Canvas SDK. So a DayBack user has no more and no less access to their Salesforce data than when they're on your other Salesforce pages.
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:
This includes the "Calendar Sources" shown above as well as any settings changes in the "Admin Settings & Defaults" section: things like the default view, time increment, the start time of your view, etc.
DayBack also stores the names of your statuses and resources, your resource folder names, and your status colors. In the case of resources, it is the name of your resource stored in DayBack, not the resource's ID in those cases where your resource represents a Salesforce record.
If you've created custom actions as part of customizing DayBack, the code for those actions is stored on DayBack's servers.
Finally, DayBack records the email address of each Salesforce user who is authorized to use DayBack and actually uses the app. You may also have designated some users as DayBack admins, and those email addresses are recorded as well. Note that only identifying aspects of the user are their org iD, email address and their Salesforce record ID. No passwords or other identification about the user is stored (and this email address is not the Salesforce user's username/accountname). Here is an example of the actual data recorded for the users of DayBacks test drive org in Salesforce:
{
"group" : {
"id" : "sf-org-00D36000000ojIYEAY17381-23517tk"
},
"members" : {
"1459229742595-1900723854" : {
"account" : "[email protected]",
"admin" : true,
"id" : "1459229742595-1900723854",
"userID" : "sf-005360000015SOJAA221107-29573tk"
},
"1459305409187-0976614575" : {
"account" : "[email protected]",
"admin" : false,
"id" : "1459305409187-0976614575",
"userID" : "sf-005360000015SOUAA2-1931-93222tk"
},
"1468520557325-2375843162" : {
"account" : "[email protected]",
"admin" : false,
"id" : "1468520557325-2375843162",
"userID" : "sf-005360000015SQZAA261098-2231tk"
}
},
Here's a diagram of how data moves between Salesforce, the user's browser, and DayBack's servers:
This data is backed up daily and retained for 30 days.
What about sharing?
The sharing feature in DayBack is explicitly designed to publish calendar data to folks outside your Salesforce org. You can turn this capability off or restrict it to certain users. When you manually create a public bookmark, that is the only time event data can leave Salesforce. Details on how this works and what data is actually published can be found here: sharing. Sharing is like exporting your event data, A share recipient has no access to your Salesforce org. Bookmarks that are "shared" with "just me" or with "my group" are not available outside Salesforce in this manner: only bookmarks set to "public" see their data leave Salesforce.
Infrastructure
Where are DayBack's servers?
The storage for dayback.com is on a Firebase Cloud Firestore server in the United States (learn more about Firebase locations). During DayBack's security review with Salesforce, the review team looked closely at all traffic between DayBack and the server to ensure all traffic was over wss (secured web sockets).
Our application is hosted on Digital Ocean's servers in their SFO2 location in San Francisco.
Encryption
Data is encrypted at rest and in transit. At rest, data is encrypted with server-side encryption: Firebase manages the cryptographic keys on our behalf using the same hardened key management systems that Google uses for their own encrypted data, including strict key access controls and auditing. Each Firestore object's data and metadata is encrypted under the 256-bit Advanced Encryption Standard, and each encryption key is itself encrypted with a regularly rotated set of master keys.
In transit, we use Transport Layer Security (TLS).
Datacenter certifications
The Firebase Cloud Firestore services have successfully completed the ISO 27001, ISO 27017 and ISO 27018 evaluation process, along with SOC 1, SOC 2, and SOC 3. Details here.
DigitalOcean is certified in the international standard ISO/IEC 27001:2013. Details.