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
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
prompts are filtered using Azure content filtering
prompts and responses are not stored or reviewed by Microsoft (Azure abuse monitoring)
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.