Security.
Ablaze Collective ("Ablaze") is committed to providing a robust security program that protects each customer's information used and processed by Ablaze for providing our products and services. The following security documentation describes the administrative, physical, and technical safeguards Ablaze maintains to protect the security, confidentiality, and integrity of customer data while connecting, replicating, and loading data from all your cloud accounting systems. To learn more about Ablaze security in detail, see our security white paper. Any terms used but not defined herein shall have the meanings assigned to them in the Ablaze Master Subscription Agreement.
Company Policies
Ablaze requires that all employees comply with security policies designed to keep any and all customer information safe, and address multiple security compliance standards, rules, and regulations.
Two-factor authentication and strong password controls are required for administrative access to systems.
Security policies and procedures are documented and reviewed on a regular basis.
Current and future development follows industry-standard secure coding guidelines, such as those recommended by OWASP.
Networks are strictly segregated according to security level. Modern, restrictive firewalls protect all connections between networks.
Responsible Disclosure Policy
At Ablaze, we are committed to keeping our systems, data, and products secure. Despite the measures we take, security vulnerabilities will always be possible.
If you believe you’ve found a security vulnerability, submit a Responsible Disclosure Form. Include the following details with your report:
Description of the location and potential impact of the vulnerability.
A detailed description of the steps required to reproduce the vulnerability (POC scripts, screenshots, and compressed screen captures are all helpful to us).
Make a good faith effort to avoid privacy violations as well as destruction, interruption, or segregation of services and/or data.
Your Organization Permissions
Users can use Single Sign-On with SAML 2.0.
Only users of your organization registered within Ablaze and Ablaze operations staff have access to your organization's Ablaze dashboard.
Your organization's Ablaze Dashboard provides visibility into the status of each integration, the aforementioned metadata for each integration, and the ability to pause or delete the integration connection - not organization data.
Organization administrators can request that Ablaze revoke an organization member's access at any point; these requests will be honoured within 24 hours or less.
Connectors
Connections to customers' database sources and destinations are SSL encrypted by default.
Ablaze can support multiple connectivity channels
Connections to customers' software-as-a-service (SaaS) tool sources are encrypted through HTTPS.
Permissions
Databases and API cloud applications - Ablaze only requires READ permissions. For data sources that by default grant permissions beyond read-only, Ablaze will never make use of those permissions.
Destinations - Ablaze requires the CREATE permission. This permission allows Ablaze to CREATE a schema within your destination, CREATE tables within that schema, and WRITE to those tables. Ablaze is then able to READ only the data it has written.
Web Portal Connectivity
All connections to Ablaze's web portal are encrypted by default using industry-standard cryptographic protocols (TLS 1.2+).
Any attempt to connect over an unencrypted channel (HTTP) is redirected to an encrypted channel (HTTPS).
To leverage HTTPS, your browser must support encryption protection (all versions of Google Chrome, Firefox, and Safari).
Solution Infrastructure
Access to Ablaze production infrastructure is only allowed using hardened bastion hosts, which require an active account protected by MFA (multi-factor authentication) to authenticate. Further access to the environment and enforcement of least privilege is controlled by IAM (identity and access management) policies. Privileged actions taken from bastion hosts are captured in audit logs for review and anomalous behaviour detection.
Physical and Environmental Safeguards
Physical and environmental security is handled entirely by our cloud service providers. Each of our cloud service providers provides an extensive list of compliance and regulatory assurances, including SOC 1/2-3, PCI-DSS, and ISO27001.
See the Google Cloud Platform compliance, security, and data center security documentation for more detailed information.
Amazon
See the Amazon Web Services compliance, security, and data center security documentation for more detailed information.
Azure
See the Azure compliance, security, and data center security documentation for more detailed information.
Data Access Options
You can choose which level of data access to grant Ablaze. The levels of access are as follows:
Source Access allows a Support Engineer or Connector Engineer to make API requests using the same token that Ablaze uses. We can then see the responses Ablaze receives from the source API during a sync and debug specific issues. With source access, we can also perform mock syncs, which use the same code as true syncs. While we can see each step of the sync to troubleshoot errors, it's not a real sync and so no data is written to the destination.
Destination Access allows a Support Engineer or Connector Engineer to run SELECT queries using the same read-only permissions granted to the connector database user. We can then validate discrepancies and debug specific issues.
Group Access grants source access for all connectors within the given group, as well as destination access.
Account Access grants source access for all connectors within the account, as well as destination access for all groups.
Debugging Environments
We create a unique debugging environment for each troubleshooting case. The debugging environment is created in the region of your data syncs, so it has the same data residency as your normal syncs. We automatically delete the debugging environment and all associated data after seven days.
Data Access Security Protocols
We follow multiple security protocols to protect your data while it's in the debugging environment. To connect to the debugging environment, our Support Engineer must authenticate with our company single-sign-on (SSO). The SSO requires multi-factor authentication (MFA), which enforces the use of a one-time passcode and an Ablaze-issued laptop. The laptop is managed by our IT department through mobile device management (MDM) software. Our MDM controls include the following:
Full-disk encryption (FDE)
MFA authorization through Ablaze's SSO
Device firewalls
Device's screen locks after 15 minutes of inactivity
Anti-malware software
Hybrid Deployment
Since your connectors run in your own environment, Ablaze doesn't have or request access to your data. We collaborate with you to troubleshoot, since only you have access to your data.
Self-hosted Deployment
Since your connectors run in your own environment, Ablaze doesn't have or request access to your data. We collaborate with you to troubleshoot, since only you have access to your data.
Certification Verification
Transport Layer Security (TLS, also referred to as Secure Socket Layer, HTTPS, or SSL) is one of the encryption methods that Ablaze uses to secure data in motion. TLS allows for both encryption and authentication of the connections that Ablaze makes to your data sources and to your destinations.
Ablaze connections made over TLS are always encrypted, and support automatic verification for connectors that use hostname verification (such as web-based applications), and for proprietary systems with built-in certificate authority management such as Snowflake, BigQuery, and Redshift.
For other connectors, such as customer-operated databases, we support verifying a certificate using root certificate authority verification.
Verifying a certificate
Connectors require a user to explicitly select the certificate to use as the trust anchor. Customers who use self-signed certificates for their databases can do the verification based on the fingerprint of the certificate, and customers who use a certificate authority model can select the authority which Ablaze should validate against.
Auditing trusted certificates
The account page in your Ablaze dashboard includes a section where your security team can audit all the trust selections that have been made within your Ablaze configuration. You have the option to revoke the trust of a certificate at any time. Once a certificate’s trust has been revoked, you will need to re-run the setup tests for any affected connectors to select the new certificate and resume data replication.