Within GRAX supplied infrastructure, all traffic is encrypted in flight via HTTPS/SSL at TLS 1.2 or higher with a public certificate (behind the ALB we recommend self-signed certificates). All data stores are encrypted by - at a minimum - AES-256. GRAX offers a pre-built secure architecture via the AWS Marketplace but choosing to use the GRAX Software on custom architecture enables you to build your own security model. As such, any operations including the transmission of network traffic or the storage of data at rest which take place on customer-provided/operated infrastructure are the responsibility of the customer.
GRAX uses a standard JSON Web Token () authentication flow to secure the Managed Package to Backend/Instance traffic. This is specifically traffic that the Managed Package sends to submit data, triggers, or configuration changes to the backend.
The secret used to drive the JWT authentication is generated on app installation/deployment and stored in an encrypted state in the app database. This is then passed into the Salesforce Managed Package by one of your Salesforce administrators after installation. Randomly generated via secure means that at a length of at least 30 characters, the complexity of brute forcing such a token is considered implausible. Rotation of this token isn't supported via automated means but can help provide relevant details via a support request.
This token is submitted in the x-api-token header as part of every API request from the managed package to the backend which contains, accesses, or controls data. Endpoints such as job summary reports (which contain only object names) aren't secured for ease of sharing/review. These paths, however, are all the concatenation of many randomized IDs and not regarded to be "guessable."
The full list of token secured endpoints isn't available for security reasons.
The GRAX Tokens are stored on the Salesforce side within a protected custom secret. For more information on these, see . Modification to these values is accomplished via the GRAX Managed Package GUI.
When the backend receives a request from the Managed Package that requires authentication, it verifies the supplied API token against the token loaded in the app configuration. This configuration loads the contents of the connected AWS Secret, sources the value from the attached Database, or reads from the local environment on each boot.
Joe Smith is an ABC Company Salesforce Administrator. He is newly responsible for configuration and maintenance of the GRAX Managed Package as well as the related data backup operations. He logs into Salesforce, chooses the GRAX app from the "app launcher," and is greeted by the GRAX "Configuration" tab. He switches to the "Schedule" tab and selects "Execute Now" on an existing backup job. This sends a request to the backend, secured via the afore-mentioned token, which is verified against the expected token value. This request adds the backup job to the internal work queue.
Within the GRAX Application experience, authentication is driven by the user's Salesforce access. Via this control, your admins can completely prevent access to GRAX, hide fields, hide features, and/or grant permission to modify general app settings.
There are always two login types to consider with GRAX: the integration user (for backing up/archiving/restoring data) and the user that logs into the GRAX interface to run said archives, restores, or searches. The integration user must have extensive permissions and be connected to the GRAX backend via OAuth. To be a user of GRAX, your Salesforce user must be given a custom permission set, named along the lines of "GRAX - [Name]" (that is "GRAX - Configuration Admin").
Please note that 'Log In As' () does not work with OAuth
The OAuth flow for the GRAX Application consists of multiple steps. First, the GRAX backend calls out to hq.grax.com with the OAuth request. This GRAX service then proxies that request to Salesforce, relating it to a unified GRAX Connected App configuration. After generating an access token for the user session, this GRAX service discards the session token and passes the access token back to the backend. The backend then uses the received access token to generate a new session.
This multi-party flow is a requirement of GRAX licensing processes as well as ensuring GRAX works under several of the more restrictive Salesforce security options. No credentials, session tokens, or access tokens are stored within the GRAX beyond the lifetime of the specific authorization events they're related to. All related data stores are encrypted. Login attempts against the user as part of this flow originate from 3.232.229.75.
GRAX respects and "row" (record) level visibility to protect your sensitive data. If a user doesn't have access to data within Salesforce, they won't be able to view that same data in the GRAX Application or Lightning Web Components. For added guarantees you can prevent integration user access to specific data so that it can never be seen, read, backed up, archived, or restored by GRAX and thus avoid the whole end user access issue in the first-place. We don't recommend this, as that data cannot be protected in backups in this case. To manage this visibility, simply manage it as your normally would in Salesforce.
GRAX drives Application access permissions based off of custom permission sets which are installed alongside the managed package and can be customized by advanced users. To grant a user access to the permissions covered under a permission set, simply assign them that permission set.
Joe Smith is an ABC Company Salesforce Administrator. He is newly responsible for restoring all Cases to their value as of last Friday. He connects to the GRAX Application URL (unique for each customer), logs in with SSO via his intended Salesforce org, and navigates to the "Restore" page. He chooses a Salesforce report as the source for Case IDs from a list populated by the backend polling the Salesforce REST API with the integration user's OAuth session token. After clicking next, the restore execution begins processing. During this time, the GRAX backend is querying the Salesforce API and GRAX storage to build a restore plan for the cases. Once Joe triggers the restore execution to run after processing is complete, the GRAX backend begins submitting REST calls to the Salesforce API with the integration user's session token to create records.
Jane Smith is an ABC Company Support Associate. She receives a customer complaint referencing a major case from 13 months ago. ABC Company's Salesforce leadership has opted to archive any cases last modified more than 9 months ago with GRAX. Jane navigates to the "Related" tab on the Account record and uses the GRAX Related Records component to see the archived case record, review the fields, and even restore that case along with related records (via linking into the GRAX Application). All data retrieval in this scenario and the potential jump into the GRAX Application are powered by Jane's OAuth session with her Salesforce org. The API calls for records originate on Jane's machine, and are verified via the OAuth process when they arrive at the GRAX Application.
Telemetry information, app level statistics about the internal performance of the GRAX system, is sent out to hq.grax.com on a regular interval. This information doesn't contain any of your Salesforce data. The connection to hq.grax.com is write-only and secured via a combination of username and password used in the basic authentication process.
Authentication to the app database is protected via "Password" authentication, as seen . No other authentication methods to the database are currently supported. GRAX does not use SSL with Certificate Verification on Postgres databases; no action is needed regarding Root Certificates or Certificate Authorities as this will not impact the application.
As a general rule, the GRAX product supports the most common and accepted authentication methods for each bucket/blob storage provider. Details for each are linked below:
GRAX periodically conducts its own penetration tests, undergoes external penetration tests, and completes other security audits. These results are available to our customers via the GRAX Trust Center. To view the results, click Request Access, and you'll receive a notification once access has been granted.
If you are interested in performing your own penetration tests of GRAX, please contact with details of your testing processes and schedule to get approval for any penetration testing.
Our cloud service providers also publish their own security reports and penetration testing guidance:
AWS GovCloud (US) Region is an isolated Amazon Web Services environment used by US government agencies at the federal, state, and local levels, along with contractors, researchers, educational institutions, and other US customers.
GRAX has received the
GRAX is compatible with
You deploy GRAX into your GovCloud cloud PaaS such as AWS, Google Cloud, Azure, and others. In fact, many agencies and customers deploy and manage their own GRAX deployment in their cloud with the majority of our customers using AWS, Google Cloud, Azure, or a hybrid or multi-cloud environment. Other customers find that they can install and run a self-managed deployment of GRAX by placing it in a GovCloud-authorized data center and using a GovCloud-authorized Cloud Service Provider.
GRAX doesn't have access to the data or infrastructure
Customer data is 100% owned by the customer within their GovCloud certified infrastructure
Customers can use private routing between Salesforce and AWS
Customers can use private routing between their infrastructure to GovCloud certified PaaS environment
GRAX architecture and deployment model has received the
To learn more about GRAX and how we support public sector agencies, departments, and organizations, please contact us. For more information on AWS's compliance with federal and other standards, see .
GRAX is a purpose-built high-security data processing app designed to deliver an efficient backup, archive, and restore experience while satisfying the regulatory and compliance requirements that customers face. Security is a primary design factor in all components of the GRAX Application, including infrastructure designs.
At GRAX we know we are in the privileged position of handling our customers' most valuable asset - their data. We are committed to our customers and their reliance on GRAX to handle their data correctly and in accordance with the regulatory frameworks they need to comply with. As an organization, we are committed to operating with honesty, integrity, and compliance.
GRAX has been audited to achieve SOC 2 Type 2 compliance across the platform. Alongside our security audits, our Salesforce Managed Package has been vetted and passed a rigorous and ongoing by Salesforce. GRAX is deployed into public cloud ecosystems and builds upon the security and compliance posture of those underlying services. For details on our compliance audit, contact .
If you require the provision of a BAA to support your HIPAA compliance, contact .
GRAX provides customers with mechanisms for authorized users to permanently delete data related to an individual (or multiple individuals). This feature is available within all product offerings.
Salesforce customers can support their PCI compliance by using Encrypted Custom Fields as the mechanism to store sensitive payment data in their Salesforce app. The GRAX Application respects the Salesforce sharing and permissions model, so individual customers can configure the GRAX user with "View Encrypted Data" permission according to their needs. Data that is handled by GRAX is encrypted in transit using TLS 1.2 and data at rest can be encrypted according to the service provider chosen.
GRAX fully adheres to Salesforce's field and encrypted visibility settings. If a field is hidden from a user of your Salesforce org, they are unable to view that data in GRAX in any capacity. If fields are encrypted in Salesforce, GRAX must have the related permissions to view that data before it can back it up or modify it.
The GRAX Application can be run in a number of public cloud providers. GRAX uses AWS as a primary infrastructure provider, but also supports customer-managed installations in Azure and GCP. For the underlying security and compliance documentation for those platforms, please refer to the relevant provider's documentation.
All data is encrypted in-flight with TLS 1.2 and encrypted at rest with each provider's standard data storage encryption (that is AWS's AES-256).
The GRAX Application server only processes and responds to HTTPS requests. HTTP requests are ignored/rejected.
GRAX uses the app database for storage of the configuration values that control connections to storage and Salesforce as well as licensing information. it's recommended that the entire database storage volume be encrypted by default; regardless, GRAX encrypts the secrets additionally before they are stored in the database. This means that even users with access to the database cannot read those values without the key utilized by the GRAX Application.
In the Salesforce Managed Package, GRAX uses a Protected Custom Setting inside Salesforce to store tokens required for authentication. This is recommended practice as part of the provided by Salesforce.
Previous versions of the GRAX Platform have been deployed to customers using the Heroku PaaS. Heroku provides customers a network isolated environment called a Private Space that has previously been used when provisioning GRAX for customers. If you would like the compliance and security information that is particular to this type of legacy configuration, please contact .
Customers data is 100% owned and stored within their GovCloud PaaS environment
For GRAX-Hosted and GRAX-Managed deployments of the GRAX Application, customers can take advantage of GRAX-provided secure endpoint technology to reduce cost, improve security posture, reduce infrastructure complexity, and shorten initial deployment time.
GRAX utilizes a third party service, ngrok, to expose applications at controlled domain names. Each application generates a subdomain on secure.grax.io when it first starts and this subdomain is used to access the application. This subdomain is unique to the application and is secured with a globally unique set of credentials. Every time the GRAX Application launches, it establishes a connection with the ngrok services, creates a tunnel, and begins serving content at the associated subdomain.
ngrok is third-party service that provides secure networking tools for internal and production use cases. Their can be found here, and their trust site with compliance and security information can be found . GRAX uses the ngrok product as a SaaS component of select provided services.
In a traditional cloud infrastructure stack designed to run a monolithic internet facing application, the following components are required just to get traffic in to the application securely (some data storage resources are absent from this list for simplicity):
Public Domain Name
Application Load Balancer
DNS entry to direct traffic to the Load Balancer
Web Application Firewall
In GRAX-managed deployments, only the application server is necessary to serve traffic. This reduces complexity of the infrastructure and reduces the overall cost of ownership of GRAX. This also means that all GRAX-managed and hosted deployments share the same ingress pattern (not secrets), making all applications part of a consistent monitoring, security, and maintenance process regardless of Cloud Provider and installation environments.
Environments deployed to use a secure endpoint are, at the infrastructure level, configured with zero means of external ingress to any resource. The application server is not reachable from outside the containing security group or VPC/VNET and data stores are only accessible from the application server. This means that there is a reduced risk of extraneous or accidental exposure of attack surfaces as doing so would require substantial changes to network security resources instead of a mere misconfiguration of a security group or VPC/VNET.
Additionally, since the GRAX Application never binds to a static pre-determined port in these deployments, the opportunity for a malicious service to take over that port and serve traffic from your ALB is eliminated. The GRAX Application creates, maintains, and protects the tunnel to the ngrok service as part of the application lifecycle, not as a static configuration within the server file system. The secrets that are used to establish the tunnel are unique to the application and are not stored locally on the server.
If customers wish to take a advantage of additional features of ngrok such as custom domains, integrated WAF, DDoS protection, etc., they can do so by contacting GRAX Support.
Requiring a public domain name, DNS changes, and an ingress path infrastructure that may be run in an otherwise isolated network segment can add significant time and complexity to any deployment of GRAX. This often means that several teams need to be involved immediately in the deployment process before even the first resource gets deployed. A secure endpoint avoids the need for those resources, allowing the GRAX Application to be deployed and running in minutes instead of hours or days.
GRAX is an enterprise solution under constant development and improvement. This includes reliability, efficiency, performance, cost, security, and portability improvements that allow the application and service to meet the goals of a varied customer base. Architectures that reduce the dependency on cloud provider specific services and resources allow GRAX to install across competing providers (AWS, Azure, GCP), across environments of different scales (Cloud, On-Prem, Docker, or a Laptop), and across different deployment models (Managed, Hosted, Self-Managed) with minimal inconsistencies between environments.
This also means that the application environment itself is more portable since connectivity of end users is controlled by the application. Failing over to an alternative geographic zone or region does require changing the ingress path or modifying DNS rules on the fly. Simply boot the application with data stores that contain the same information in a new region, account, zone, or even cloud provider, and focus on the rest of your business.
GRAX-managed and GRAX-hosted applications are designated to use a secure endpoint upon creation within . When the infrastructure deployment is completed, the application checks in with hq.grax.com for purposes of licensing, telemetry, and secure endpoint management. The application then establishes a connection with the ngrok service based on data retrieved from hq.grax.com. This interaction with ngrok happens entirely within the GRAX Application via the ngrok . When the GRAX Application is offline, a default error page is displayed by ngrok automatically whenever someone tries to access the application subdomain.
If you have any remaining questions about GRAX secure endpoints, please reach out to GRAX Support for more information.
GRAX monitors deployed software via egress-only log and telemetry streaming technologies. This allows the GRAX team to best ensure reliability without need for ingress connections or direct environment access, both of which have security implications. This document explains both of the methods in use today by GRAX and describes the data contained by both.
Metrics are quantitative expressions of app performance, health, and configuration; their numerical nature assists in detection of failures. GRAX calculates and streams metrics continuously as the app runs. Telemetry regarding system resources (CPU, RAM, Disk, etc.) is streamed continuously, but the GRAX Application submits specialized telemetry events occasionally. These include, in part:
At time-of-boot
At time-of-update
Changing configuration of:
Backup
Search
Data Lake
Processing tasks change status (created, started, ended, failed, etc.):
Archives
Restores
Logs are more detailed and structured than app metrics; they're traditionally used for investigating issues -- not detecting them. GRAX streams logs with an authenticated egress-only connection, making application logs available to GRAX Engineering for the sake of supportability and bug-fixing. Here are some related key details:
GRAX logging never contains your Salesforce records or any system secrets.
Logs use the same authenticated hq.grax.com connection as licensing and metrics.
Access to these logs is tightly controlled internally at GRAX.
Logs are retained indefinitely.
Logging uses a forward-only collector and won't transmit logs from an earlier point in time.
Logs emitted by GRAX never contain customer CRM data, PII, or secrets. These logs are intentionally designed to be useful for GRAX engineers; as such, they contain:
Source Function Names
Source filenames
Function Timing Information
API Request Methods
As you can see, the data logged within the GRAX logging system is strictly related to operation and performance of the GRAX Application with no exposure of protected data at any time.
As stated above, logs from GRAX are intended for consumption by GRAX engineers. We don't publish documentation nor provide training on understanding the internals of the GRAX Application. This means that logs won't provide value to teams monitoring GRAX directly without the assistance of GRAX support.
Your logs are only visible to the engineers who directly support and manage operation of the GRAX Application. For more information about security controls, audits, and compliance, see .
This is required for the GRAX Application to operate. As such, egress to hq.grax.com is required at all times from the app. A static IP for this communication isn't currently available. Without this access, the app won't boot or run; this isn't configurable.
GRAX takes security of customer data seriously. As such, none of your Salesforce data ever leaves the app environment. A breakdown of collected data follows:
Names of Salesforce objects (Standard and Custom) covered by backup and archive operations.
Number of records for Salesforce objects (Standard and Custom) covered by backup and archive operations.
GRAX backup/archive/restore configurations (schedule, start time, etc) and statuses.
Size, performance, and internal metrics for the proprietary GRAX storage layer in your storage bucket.
No sensitive, classified, or restricted data or PII is included in telemetry communications. The content of backed up records isn't inspected for telemetry, nor is it made available to any GRAX engineers.
All data is encrypted with HTTPS and TLS 1.2+ while in flight, and encrypted on disk when at rest. Access to the telemetry dataset is restricted within the GRAX team to only engineers whose roles require access.
GRAX uses third party tools and services to protect, store, and analyze telemetry data. The current telemetry tool set includes:
for ingestion and consumption
for archival
Telemetry archives are encrypted at rest with AES-256 encryption.
GRAX forwards app logs to a central GRAX service to help with automatic monitoring and customer support. GRAX retains these logs indefinitely. For more details see here .
However, in self-managed GRAX deployments, you are in control of the configuration of your GRAX Application servers, and can configure them to forward logs to your own external storage systems.
How to do this depends on how your server is configured to run GRAX, as well as what log storage system you use. If you are using the standard GRAX AWS templates, GRAX logs go through:
systemd journal
rsyslog
/var/log/grax.log
AWS CloudWatch
Consult with your cloud team and logging service provider on how to configure the server to forwarding from one of these subsystems.
In self-managed GRAX deployments, after you forward logs to your own logging service, you also are in control of how these are used, and can use them for auditing, monitoring and alerting.
While the format of application logs is subject to change, every API call is logged and includes:
HTTP method, path, and status
Remote address and user agent
Salesforce Org ID and User ID of the caller
Here is an example log for when the user with ID 0054o000002Yz6lAAC updated storage settings:
This cannot be disabled.
CPU Performance Metrics / Profiles
Memory Performance Metrics / Profiles
Storage Performance Metrics / Profiles
Function Metadata (Object Names, Batch Sizes, Record Counts, etc.)
Size and performance metrics for the attached Postgres database.
Total data size sent and received to/from Salesforce.
Feature status (feature flags, feature access levels)
Structured app logging (optional)
{"keys":{"jwtAuth":"sfid_00D770000008i1kEAA_0054o000002Yz6lAAC","method":"PUT","path":"/api/v1/secrets/StorageSecret","remoteAddr":"[2600:1700:9da3:c850:3c02:8217:4d9f:2507]:52529","route":"/api/v1/secrets/:id","status":200,"userAgent":"Mozilla/5.0"}}The Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. See the GSA definition.
Specifically, FedRAMP is focused on cloud products and services, evaluating and certifying cloud PaaS, IaaS, and SaaS offerings. Details about the FedRAMP program highlight the process and status of how cloud services are assessed and certified in the FedRAMP marketplace.
You deploy GRAX into your FedRAMP cloud PaaS such as AWS, Google Cloud, Azure, and others. In fact, many agencies and customers deploy and manage their own GRAX Application in their cloud with the majority of our government customers using an on-premise deployment of our software product in their cloud environment (like AWS, Google Cloud, or Azure) or in a hybrid or multi-cloud environment. Other customers find that they can install and run the GRAX Application by placing it in a FedRAMP-authorized data center and using a FedRAMP-authorized Cloud Service Provider.
To learn more about GRAX and how we support public sector agencies, departments, and organizations, please contact us.
For more information on AWS's compliance with federal and other standards, see .