Skip to content
Platform & Configuration
Configuration
Security Best Practices

Security Best Practices for Astralis Deployment and Operation

Astralis 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 Astralis.

Deployment Diagrams

Generic Deployment Diagram

  • The hosted fides data stores (Postgres & Redis) must be deployed before Astralis itself can be deployed. These data stores should be dedicated to Astralis. 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 Astralis 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 Astralis, but Astralis must not be deployed to production without it.

Generic Deployment Diagram

Public Ingress: TLS Termination of Inbound Traffic

The Astralis 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 TLS Termination Diagram

Public Ingress: Route Allow-Listing for Inbound Traffic

Exposing all Astralis 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 Astralis webserver to allow-list only the minimum set of routes required by external users.

Public Ingress Route Allow Listing

Public Internet → Privacy Center UI

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

Trusted Internal Networks → Astralis Webserver

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

Public Internet → Astralis 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 Astralis Mobile SDK, additionally:

  • GET /api/v1/plus/tcf/decode_mobile
Privacy Center as a consent experience

For deployments that use the Astralis 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
  • GET /api/v1/plus/privacy-request-metrics/{organization_fides_key}

The second route returns the same metrics scoped to a single organization. Allow-list it only if you publish per-organization disclosure figures. Because it is unauthenticated and returns 404 for an organization key that does not exist, anyone who can reach it can determine which organization keys exist in your deployment. Organization keys are not secrets, but if you consider the list of organizations in your deployment sensitive, do not expose this route to the public Internet.

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 Astralis 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 Astralis:

  • 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

Respondents whose access link has expired, been lost, or never arrived can self-serve a replacement without contacting support:

  • POST /api/v1/plus/external-login/request-new-link

This endpoint always returns the same 200 response, regardless of whether the submitted email address belongs to a portal user, to avoid leaking which addresses are registered. It is rate-limited (auth_rate_limit in the [security] section of fides.toml), and the fresh link is only ever sent to the email address already on file for the resolved user, never to a caller-supplied address.

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 Astralis 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 an Astralis 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:

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. 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 Astralis 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.

Privacy Center Front-End Cache

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 (opens in a new tab). 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.
  • [Astralis 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 Astralis 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 (opens in a new tab)
  • [DevOps] If feasible, use a secrets management system such as AWS Secrets Manager or Hashicorp Vault.

Encryption

Encryption in Transit

  • [DevOps] The Astralis containers are designed to be deployed behind a reverse proxy for TLS termination (also known as SSL/TLS offload). When deploying Astralis 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 Astralis containers. Commonly used methods include:
    • Deny all inbound traffic to Astralis 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

  • [Astralis 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 - see Configuration for more info.
  • [Astralis 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 - see Configuration for more info.
  • [Astralis Webserver Config] Configure a remote storage destination e.g. an S3 bucket with default server-side encryption (opens in a new tab). Do not store DSRs locally on the container’s ephemeral filesystem.

Application Traffic

  • [Astralis 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 - see Configuration for more info.
  • [Astralis Webserver Config] Configure a sensible value for the Astralis 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 Astralis receives. request_rate_limit in the [security] section of fides.toml - see Configuration for more info.
  • [Astralis Webserver Config] Enable authentication for all Astralis webserver API endpoints by setting env = "prod" in the [security] section of fides.toml. If this is not explicitly enabled, then by default the Astralis webserver allows all inbound traffic to all API endpoints and front-end paths. This includes potentially dangerous Astralis API endpoints such as /api/v1/admin/db/reset. See Configuration for more info.

Reverse Proxy

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 Astralis 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 Astralis containers to any destination.

Logging

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

Hosted Astralis Data Stores

Hosted Astralis Database (PostgreSQL)

  • [Hosted Database Config] Use the latest minor version of a supported major release (opens in a new tab) 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 Astralis Webserver user to authenticate to the database.
  • [Hosted Database Config] Allocate the minimum role attributes (opens in a new tab) needed to the Astralis Webserver database user.
  • [Hosted Database Config] Configure the hosted database to allow encrypted connections only.
  • [DevOps] Allow-list network traffic to/from the Astralis Webserver only. Implicitly deny all other traffic e.g. to the public Internet.

Hosted Astralis Cache (Redis)

  • [Hosted Cache Config] Use a stable, supported version (opens in a new tab) of Redis.
  • [Hosted Cache Config] Use a dedicated hosted cache, do not share it with other applications.
    • Allow-list network traffic to/from the Astralis Webserver only.
    • If the cache cannot be dedicated and must be shared with other applications, use Redis ACLs (opens in a new tab) to manage cache authorization.
  • [Hosted Cache Config] Use Redis TLS support (opens in a new tab) to only allow TLS/SSL encrypted connections. Note that this will have a performance impact (opens in a new tab).
  • [Astralis Webserver Config] Configure the Astralis Webserver to enable TLS/SSL for Redis traffic. ssl = True in the [redis] section of fides.toml - see Configuration for more info.
    • If the hosted cache supports it, also set ssl_cert_reqs = "required" in the same configuration section. Note that some cache platforms e.g. Elasticache may not support this.

Remote Storage Destination

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

PropertiesDeployment Options