Skip to content

Using Zero Trust in Applications

this is a must have for all new endpoints at statista

Requirements

All new endpoints at Statista must implement Zero Trust principles. Depending on the type of application or integration, the following mechanisms should be used to enforce security at the communication layer (in order of precendence):

  1. OAuth 2.0 via Okta

    For internal tools with access for employees, ensure that access is granted only to active employees:

    • Use Okta to manage authentication.
    • Integrate OAuth2 flows or OIDC with Okta for robust identity federation.

    This is implemented in Dev-Env Authenticator and could be seen as a blueprint.

  2. OAuth 2.0 via Auth0

    For public applications for our customers, ensure access is check agains the SSO infrastructure and only to active customers. This should include APIs where access to the endpoint could be validated by identified customers (it excludes endpoints where anonymous access is valid and expected:

    • Leverage OAuth2 authorization flows, especially for multi-tenant and mobile use cases.
    • Use Auth0 as the identity provider where appropriate.
    • Implement token validation, expiration handling, and scopes for least-privilege access.
    • Use refresh tokens securely, following best practices to avoid misuse.

    This is implemented in in Remix SSO and could be seen as a blueprint.

  3. API Keys

    If access is allowed by non-customers or in a way where customer identifcation is impossible, API Keys (e.g. by using the AWS APIGateway) should be used:

    • Generate scoped, time-limited API keys.
    • Store keys securely (e.g. AWS Secrets Manager) and implement key rotation.

    no example implementation available yet

  4. Client Certificates

    For highly sensitive, internal, or machine-to-machine communication where stronger authentication is necessary:

    • Use mutual TLS (mTLS) with client-side certificates issued by a trusted CA.
    • Automate certificate issuance and renewal (e.g., via Cert-Manager, HashiCorp Vault PKI, or AWS ACM).
    • Ensure endpoints validate client certificates and apply access policies based on certificate identity.
    • Revoke certificates promptly in case of device compromise or credential leakage.

    no example implementation available yet

  5. Pre-Shared Secrets

    For simpler internal services or automation scripts where advanced identity federation is not practical:

    • Use strong, randomly generated secrets.
    • Secrets must be stored securely (e.g. AWS Secrets Manager).
    • Implement secret rotation policies; manual rotation is not sufficient - automation is preferred.
    • Avoid hardcoding secrets in codebases or environment files without encryption.

    This is implemented in Dev-Env Authenticator (with manual secret rotation for now) and could be seen as a blueprint.

Implementation Guidelines

the following guidelines should be followed when implementing Zero Trust through Secrets that needs to be shared and rotated throughout the organization.

Secret Sharing

Secrets should be shared securely and only with authorized parties. For storing such secrets, we recommend using AWS Secrets Manager or AWS Systems Manager Parameter.

There are 2 official ways of doing it properly:

Secret Manager

see AWS Secrets Manager

  1. Encrypt the secret with a customer managed KMS key.
  2. Attach a Resource-Policy to the Secret that allows access to it from different AWS accounts or IAM roles.
  3. Attach a Resource-Policy to the KMS key that allows access to it from different AWS accounts or IAM roles.

Parameter Store

see AWS Systems Manager Parameter Store

  1. Encrypt the parameter with a customer managed KMS key.
  2. Add the Parameter to AWS Resource Access Manager (RAM) to share it with other AWS accounts.
  3. Attach a Resource-Policy to the KMS key that allows access to it from different AWS accounts or IAM roles.

Revocation

for revoking access to secrets or parameters simply remove access from the Resource-Policy of the Secret or RAM. Afterwards you should immediately rotate the key.

Secret Rotation

Rotation is mostly done with AWS Lambda functions.

Secret Manager

Rotation is a native feature of AWS Secrets Manager. A very good explanation on how rotation works in detail can be found in this article

Be aware that the application using this Secret might fail if it is rotated (if you dont fetch it everytime, which you shouldnt because of potential Rate-Limits). To mitigate that, your app must recover this error and fetch the AWSPREVIOUS version of the Secret, and use this value from now on.

Parameter Store

For the Parameter Store there is no built-in rotation feature. You can schedule a Lambda function to rotate the parameter value with the AWS Event-Bridge-Scheduler. Parameters also have Versioning, so you can still get old values.

Be aware that the application using this Parameter might fail if it is rotated (if you dont fetch it everytime, which you shouldnt because of potential Rate-Limits). To mitigate that, your app must recover this error and fetch the version-1 version of the Parameter, and use this value from now on.

Last updated: January 05, 2026 at 13:31
By: Markus Wolf