Security Architecture - Multi-tenant Chat

3 min read

Multi-tenant is the SaaS (software as a service) offering from UNIQUE that customers can directly use from the existing SaaS environment. It follows the same security architecture as the Single Tenant deployment, with the differences listed at the end of this page.

Overview

Diagram: Security Architecture_Multi-Tenant

Azure Application Gateway

  • Web application firewall is filtering all requests

  • IP blocking can be configured in the web application firewall optionally

Azure Storage Accounts

  • Blob and container soft delete for 7 days

  • Point-in-time restore for 6 days

  • PostgreSQL has automated backups with 14 days retention

Azure OpenAI Deployments

Kong Application Gateway

  • validates JWTs

SSO

  • SSO can be configured to connect to customer IDP using Entra ID, OIDC, SAML, and other methods supported by Zitadel

Encryption

  • Data in Azure Storage and Azure PostgreSQL is encrypted at rest with 2048-bit RSA-HSM keys, managed by UNIQUE

  • Data on Kubernetes volumes (search index, vector store, message queue) is encrypted at rest with AES-256, using Microsoft platform-managed keys

  • All data in transit is encrypted using TLS 1.2+

Data classification

  • Zitadel only processes and stores user authentication data

  • Redis does not store any customer data, only state

  • Azure Key Vault stores encryption keys and secrets

  • All other services and data storages store data of classification level confidential, internal or public depending on the customers restrictions on data classifications to use on UNIQUE

MS Defender for Cloud (MDC)

  • MDC monitoring and alerting on all incidents happening in the Azure landing zone resources

  • Connected to MS Sentinel SIEM for monitoring and alerting

  • 24/7 SOC monitoring of incidents for quick triage and response

Comparison with Single Tenant Deployment Model

On the multi-tenant (SaaS) chat deployment model the most notable differences from the Single Tenant deployment model are:

  • data at rest is stored in shared storage accounts with other customers

  • data at rest is always stored in Switzerland (Switzerland North)

  • data is processed on the same backend service instances with other customers

  • users are logging in on the same Zitadel instance with other customers

Data residency: what leaves Switzerland

By default, all data is stored and processed in Switzerland (Azure Switzerland North). This includes inference with Azure OpenAI models, data at rest, logs and security monitoring.

Data leaves Switzerland only in the cases below. Except for files uploaded into Unique AI Conduct, at most the prompt and the document chunks retrieved for it are sent, never full documents, and only for the duration of the request.

What leaves

When

To whom / where

Prompt and retrieved document chunks

Only in spaces where EU processing has been enabled

Microsoft Azure OpenAI or other inference models in the EU

Search query, which depending on the prompt can include parts of the prompt and retrieved document chunks

Only when web search is enabled

Microsoft Bing (global service, outside the Azure geography boundary)

Files directly uploaded into Unique AI Conduct

Only in spaces where EU processing has been enabled

Microsoft Azure OpenAI or other inference models in the EU

Data the model passes to a tool call, which can include parts of the prompt and retrieved document chunks

Only when an MCP server is connected

Operator of the MCP server, at the location where it runs

Azure OpenAI is the only model family available in both Switzerland and the EU. All other models are processed in the EU only.

Last updated