> For the complete documentation index, see [llms.txt](https://docs.aohwv.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aohwv.dev/trust-security-and-data-handling/encryption.md). # Encryption AOH Sync protects your data in transit with TLS and protects credentials at rest using an in-house secret store (the Vault). This page describes what is protected, how it is protected, and what to confirm with your deployment team for compliance purposes. *** ## Data in transit All HTTP traffic to and from the AOH Sync web interface and API is carried over **HTTPS (TLS)**. A reverse proxy (Caddy) runs as a dedicated container on the VM and handles TLS termination before any request reaches the application. Caddy's TLS configuration (certificate source, minimum TLS version, cipher suite selection) is controlled by your deployment configuration. Connections to Microsoft Graph, Entra ID, the container registry, and the license server are made over HTTPS. Internal communication between containers on the same VM uses localhost network interfaces. *** ## Credentials and secrets at rest: the Vault AOH Sync does not store credentials in its configuration database. Instead, every secret — database passwords, Azure client secrets for Entra provisioning, connector credentials, internal signing keys — is stored in the **Vault**, which is a dedicated secret-storage service running on the same VM. The Vault uses **envelope encryption**: each secret is encrypted under a per-domain key-encryption key (KEK), and KEKs are themselves protected by a root key. This means: * Connector credentials and Entra client secrets are encrypted before they are written to the Vault's storage. * The application retrieves a live credential from the Vault at startup and refreshes it on a half-TTL cadence; credentials are not stored in memory longer than needed. * The Vault supports key rotation: a `VERSION_ACTIVATED` event is streamed to subscribers when a secret is rotated, allowing the application to pick up new credentials without a restart. * A two-person break-glass workflow is available for high-value secrets via the Vault's checkout/checkin mechanism. * Operator-level Vault administration (KEK rotation, seal state, audit query) is restricted to authorized operators. *** ## Database encryption at rest AOH Sync's identity graph, relational configuration database, and in-memory cache run as containers on your Azure VM. Azure VM disks can be protected with Azure Disk Encryption, which is a platform-level control available in every Azure subscription. Whether this is enabled for your AOH Sync VM is determined by your deployment configuration and your organization's Azure policy. *** ## API authentication Access to the AOH Sync API requires one of: * A session cookie obtained after authenticating via Microsoft Entra ID (OIDC) * A short-lived JWT bearer token * An API key (for integration consumers using the public API) API keys are stored as hashed values — the plaintext key is shown only once at creation time and is not recoverable from the stored hash. JWT signing keys are stored in the Vault, not in the configuration database. *** ## Related * [The Identity Dataplane](/trust-security-and-data-handling/identity-dataplane.md) * [Where Your Data Lives](/trust-security-and-data-handling/data-residency.md) * [What Data AOH Sync Stores](/trust-security-and-data-handling/what-data-we-store.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.aohwv.dev/trust-security-and-data-handling/encryption.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.