Security Best Practices for Fides Deployment and Operation

Fides offers several configuration options to flexibly manage a variety of deployments. This guide is meant to be used as a supplement to the configuration options, and provides a summary for best practices to ensure appropriate security methods when deploying and operating Fides.

Deployment Diagrams

Generic Deployment Diagram

• The hosted fides data stores (Postgres & Redis) must be deployed before Fides itself can be deployed. These data stores should be dedicated to Fides. Access to them must be protected e.g. do not expose them to untrusted networks such as the public Internet.

• The simplest deployment model is to centralize all Fides functionality on a single fides container. However, it is possible to divide work across multiple fides containers on the same host or orchestration platform.

• The following components are optional and only deployed or integrated when using Privacy Center.

  • Privacy Center container (and UI)
  • Storage destination
  • Messaging provider

• The public ingress / reverse proxy component is not part of Fides, but Fides must not be deployed to production without it.

Public Ingress: TLS Termination of Inbound Traffic

The Fides webserver and Privacy Center services are not designed for a deployment with direct termination of TLS for inbound traffic. These services must not be exposed to users on untrusted networks. Therefore a reverse proxy or load balancer must be placed in front of them to enforce encryption of inbound traffic using TLS.

Public Ingress: Route Allow-Listing for Inbound Traffic

Exposing all Fides API endpoints to users on untrusted networks such as the public Internet is not recommended. Therefore an ingress or API gateway must be placed in front of the Fides webserver to allow-list only the minimum set of routes required by external users.

Public Internet → Privacy Center UI

Allow all routes to the Privacy Center UI container from the public Internet.

Trusted Internal Networks → Fides Webserver

Allow-list all routes to the Fides webserver from the trusted internal networks used by your Admin UI users and by any internal services or operators that call the Fides API directly.

Public Internet → Fides Webserver

Allow-list only the endpoints required by the features you have enabled. The required endpoints, grouped by feature, are listed below.

FidesJS consent SDK

For any deployment that loads FidesJS in customer-facing pages to render a privacy experience:

• GET /api/v1/privacy-experience
• GET /api/v1/privacy-experience-meta
• PATCH /api/v1/privacy-preferences
• PATCH /api/v1/notices-served
• GET /api/v1/plus/property
• GET /api/v1/plus/custom-asset/{asset_type}

For TCF experiences, additionally:

• GET /api/v1/privacy-experience/gvl/translations
• GET /api/v1/plus/gvl/vendor-list.json

For the iOS or Android Fides Mobile SDK, additionally:

• GET /api/v1/plus/tcf/decode_mobile

Privacy Center as a consent experience

For deployments that use the Fides Privacy Center as a privacy experience for end users to manage their consent:

• POST /api/v1/consent-request
• POST /api/v1/consent-request/{consent_request_id}/verify
• POST /api/v1/consent-request/{consent_request_id}/verify-for-privacy-preferences
• PATCH /api/v1/consent-request/{consent_request_id}/privacy-preferences
• PATCH /api/v1/consent-request/{consent_request_id}/notices-served

For disclosure metrics, additionally:

• GET /api/v1/plus/privacy-request-metrics

Retained for backward compatibility, superseded by the privacy-preferences variants above:

• GET /api/v1/consent-request/{consent_request_id}/preferences
• PATCH /api/v1/consent-request/{consent_request_id}/preferences

Privacy requests (data subject requests / DSRs)

For any deployment that accepts privacy request submissions from end users, including via the Fides Privacy Center:

• POST /api/v1/privacy-request
• POST /api/v1/privacy-request/{privacy_request_id}/verify
• GET /api/v1/privacy-request/{privacy_request_id}/access-package

Add GET /api/v1/id-verification/config if identity verification is enabled for the consent or privacy request flow. Add POST /api/v1/drp/exercise if you have enabled the Data Rights Protocol (DRP) integration.

Inbound consent webhooks

For bidirectional consent integrations that push consent updates from third-party systems back into Fides:

• POST /api/v1/plus/connection/{connection_key}/consent-webhook

External respondent login

For Jira manual tasks or any other manual task workflow that asks external respondents to log in. These respondents are not on a trusted internal network, so the OTP login endpoints must be reachable from the public Internet:

• POST /api/v1/plus/external-login/request-otp
• POST /api/v1/plus/external-login/verify-otp

Slack chat integration

If you use the Slack chat integration, both the OAuth installation flow and the inbound events webhook must be reachable from the public Internet:

• GET /api/v1/plus/chat/slack/authorize
• GET /api/v1/plus/chat/slack/callback
• POST /api/v1/plus/chat/slack/events

OAuth callbacks for integrations

When Fides is connected to a third-party service (a SaaS integration or an SSO identity provider), the third party redirects the admin's browser back to a Fides callback URL after authorization. Most third parties require this URL to be publicly resolvable HTTPS, so the callback must be reachable from the public Internet for the integration to be configured. Allow-list the callbacks for the integrations you use:

• GET /api/v1/oauth/callback — generic OAuth handler used by various integrations.
• GET /api/v1/plus/oauth/jira/callback — Jira manual tasks.
• GET /api/v1/plus/openid-provider/{identifier}/callback — SSO via OpenID Connect.

Admin UI authentication

The Admin UI itself should be reached from trusted internal networks. In that case, none of its login endpoints (password reset, accept-invite, the SSO flow initiator, etc.) need to be allow-listed for the public Internet. Fides Enterprise customers exposing the Admin UI more broadly should work with their Ethyca Forward Deployed Engineer to finalise a deployment-specific allow-list.

Path parameters

When configuring the allow-list, match path parameters as parameterised segments rather than hard-coded values:

• {consent_request_id} and {privacy_request_id} are server-generated UUIDs prefixed with con_ and pri_ respectively (e.g. con_4f0d00e2-730c-4ca1-9c97-2c40ec55f847, pri_ae45de5b-cb8a-4567-9784-30692d82d00e).
• {asset_type} is a custom asset name. Currently only custom-fides.css is supported.
• {connection_key} is the unique key of the Fides connection configured to receive the webhook event.
• {identifier} is the configured identifier of an OpenID Connect provider.

Privacy Center Front-End Cache

The Privacy Center UI is intended to be accessed by users on the public Internet. To improve performance for these users and reduce load on the Privacy Center UI origin server, it is recommended (but optional) to deploy a cache for the Privacy Center’s static assets between the user and the public ingress.

Security Best Practices

Version Management

• [DevOps] Deploy stable, maintained software release versions only. Re-deploy or update when new versions become available.
• [DevOps] Check regularly for new releases. Re-deploy or update when new versions become available.

Authentication

• [General] For username + password authentication:

• Is the username unique? Avoid account sharing.

  • Is the password unique? Avoid password re-use.
  • Is the password strong? A random alphanumeric string with a minimum length of 16 characters is recommended.

• [Fides Webserver Config] Set subject_identity_verification_required to True so that identity verification is required for privacy requests. This is set to False by default.

Authorization

• [General] Apply the principle of least privilege when granting users roles and permissions.
• [General] Regularly review user accounts and their privileges. Revoke access when it is no longer required. Reduce permissions if they are not needed.

Secrets Management

• [General] Avoid the use of default fides values for secrets. Configure your own unique values instead.
• [DevOps] If deploying Fides to a container orchestration platform, use the platform’s secrets management tools and apply best practices. For example, if using Kubernetes, apply Good practice for Kubernetes Secrets
• [DevOps] If feasible, use a secrets management system such as AWS Secrets Manager or Hashicorp Vault.

Encryption

Encryption in Transit

• [DevOps] The Fides containers are designed to be deployed behind a reverse proxy for TLS termination (also known as SSL/TLS offload). When deploying Fides you must ensure that traffic is encrypted when transmitted on external networks by the following.

• Deploy a reverse proxy for all inbound connections to the Fides containers. Commonly used methods include:

  • Deploying an AWS Application Load Balancer with HTTPS listeners in front of the Fides containers.
  • Deploying an NGINX server / container for SSL termination in front of the Fides containers.
  • Using an NGINX Ingress Controller for SSL termination if deploying the Fides containers on Kubernetes.
  • Deny all inbound traffic to Fides containers that does not pass via the proxy.
  • Redirect all inbound HTTP connection requests to HTTPS.

• [DevOps] For all TLS connections, ensure that TLS v1.2 is the minimum TLS version in use. Disable support for older versions.

Encryption at Rest

• [Fides Webserver Config] Generate a unique, random 32 character string for the AES app encryption key for use in your configuration. app_encryption_key in the [security] section of fides.toml
• [Fides Webserver Config] Generate a unique, random 32 character string for the PGP user data encryption key for use in your configuration. encryption_key in the [user] section of fides.toml
• [Fides Webserver Config] Configure a remote storage destination e.g. an S3 bucket with default server-side encryption. Do not store DSRs locally on the container’s ephemeral filesystem.

Application Traffic

• [Fides Webserver Config] Allow only selected, trusted domains in the Access-Control-Allow-Origin header by configuring the value of cors_origins appropriately. The values will be unique to your deployment. Avoid the use of * wildcards. cors_origins in the [security] section of fides.toml
• [Fides Webserver Config] Configure a sensible value for the Fides API rate-limit. Its value should be high enough not to block genuine traffic, but low enough to protect against automated attacks. Ethyca recommends starting with a high value before lowering it as you monitor the amount of traffic Fides receives. request_rate_limit in the [security] section of fides.toml
• [Fides Webserver Config] Enable authentication for all Fides webserver API endpoints by setting env = "prod" in the [security] section of fides.toml. If this is not explicitly enabled, then by default the Fides webserver allows all inbound traffic to all API endpoints and front-end paths. This includes potentially dangerous Fides API endpoints such as /api/v1/admin/db/reset.

Reverse Proxy

• [DevOps] The public ingress / reverse proxy component is not part of Fides, but Fides must not be deployed to production without it. The reverse proxy serves two critical security purposes: TLS support and route allow-listing.

Network Access / Firewalls

• [DevOps] Configure your firewalls to:

• Inbound

  • Allow inbound HTTPS (TCP/443) traffic to the reverse proxy from any source, including the public Internet. It’s also recommended to allow inbound HTTP (TCP/80) traffic to the reverse proxy from any source, but configure the reverse proxy to immediately redirect these connections to HTTPS.
  • Allow inbound HTTP traffic from the reverse proxy to the Fides webserver, typically on TCP/8080.
  • Allow inbound HTTP traffic from the reverse proxy to the Privacy Center UI container, typically on TCP/3000.
  • Implicitly deny all other inbound traffic.
  • Outbound
    • Allow outbound TCP and UDP traffic from the Fides containers to any destination.

Logging

• [Fides Webserver Config] Set the minimum log level to INFO or higher. Do not set to DEBUG or TRACE.
• [Fides Webserver Config] Do not set the FIDES__LOGGING__LOG_PII environment variable to True.
• [Fides Webserver Config] Do not set the FIDES__DEV_MODE environment variable to True.
• [DevOps] Incorporate Fides logging into your organization's existing log management systems for appropriate monitoring, alerting, and reporting.

Hosted Fides Data Stores

Hosted Fides Database (PostgreSQL)

• [Hosted Database Config] Use the latest minor version of a supported major release of PostgreSQL.
• [Hosted Database Config] Ensure that the database’s storage is encrypted at rest at the filesystem or block level using at least AES-256.
• [Hosted Database Config] Create a dedicated user and strong password for the Fides Webserver user to authenticate to the database.
• [Hosted Database Config] Allocate the minimum role attributes needed to the Fides Webserver database user.
• [Hosted Database Config] Configure the hosted database to allow encrypted connections only.
• [DevOps] Allow-list network traffic to/from the Fides Webserver only. Implicitly deny all other traffic e.g. to the public Internet.

Hosted Fides Cache (Redis)

• [Hosted Cache Config] Use a stable, supported version of Redis.
• [Hosted Cache Config] Use a dedicated hosted cache, do not share it with other applications.
  • Allow-list network traffic to/from the Fides Webserver only.
  • If the cache cannot be dedicated and must be shared with other applications, use Redis ACLs to manage cache authorization.
• [Hosted Cache Config] Use Redis TLS support to only allow TLS/SSL encrypted connections.
• [Fides Webserver Config] Configure the Fides Webserver to enable TLS/SSL for Redis traffic. ssl = True in the [redis] section of fides.toml.

Remote Storage Destination

Fides currently only supports S3 as a remote storage destination for DSRs.

• [Remote Storage Config] Implement the recommendations in AWS’s Security best practices for Amazon S3 user guide.
• [Remote Storage Config] Once a DSR is stored on S3 for retrieval, Fides does not manage their lifecycle. To ensure that DSR objects do not persist forever, implement a sensible storage lifecycle management configuration with expiration.