Why this matters
Organizations move critical data to cloud platforms, software services and managed databases, and trust those operators with the keys. "Encrypted at rest" sounds reassuring until you notice what it means: the provider holds the decryption key, not you. A subpoena, a breach, a rogue employee or a foreign data access law can expose your data without your knowledge. Data sovereignty concerns both who holds the keys and where storage and processing take place.
What sovereignty means
Data sovereignty concerns an organization’s authority over its data, including access, processing, placement and the laws that apply. It has three sides:
- Legal. Which country's law governs this data? Can a foreign court compel disclosure?
- Technical. Who holds the decryption keys? Can the storage operator read the plaintext?
- Operational. Can the organization move its data to another provider without losing access or breaking references?
The encryption ladder
Different encryption arrangements protect different boundaries:
- No encryption. Anyone with the disk reads the data.
- Encryption in transit. The wire is protected. The server reads everything once it arrives.
- Encryption at rest. The operator encrypts its disks and holds the key. The service decrypts data when it needs to process it.
- Customer-managed keys. The customer supplies the key, and the operator uses it during processing. In practice the operator can still read the data.
- End-to-end encryption. Authorized participants hold decryption keys; intermediaries outside that group carry ciphertext. The important question is which participants can read the data, including any processing services.
How Legra separates storage and processing
Legra encrypts workspace data before durable storage. Storage providers hold blocks they cannot read without decryption authority. Membership and key rules determine which participants can read the workspace.
An authorized query host decrypts workspace data to process queries. That host is inside the workspace’s trust boundary. You can operate it yourself or select an operator you trust. Choose both the operator and where it operates.
This distinction matters: giving a provider custody of encrypted blocks does not grant permission to process their contents. Choosing an outside query host does grant that host access to plaintext during processing.
Encryption explains these responsibilities. Workspaces explains how private, shared and public knowledge use the same model without merging access rights.
What it gives you
Explicit responsibilities. You can distinguish who stores encrypted copies from who reads and processes them. Encryption alone does not determine legal obligations or remove the need to assess location, access and processing.
Infrastructure choice. Select storage providers and query hosts separately. An encrypted storage copy and an authorized processing host have different exposure. Both choices remain part of data governance.
Storage breach protection. Someone who obtains encrypted blocks without the keys cannot read their contents. A compromised query host or authorized reader has a different exposure because it can access plaintext.
Trusted exchange. When data passes between suppliers, partners and regulators, intermediaries carry ciphertext they hold no key for. The recipient checks through signatures that nothing changed on the way.
Workspace boundaries. Each workspace has its own membership and access rules. Encryption protects stored copies; authorized hosts must also enforce those rules when processing requests and returning results.
What it costs
Key management. You generate, distribute, rotate, revoke and recover your own keys. Lose the key and the data is gone. That is the price of sovereignty.
Overhead. Encryption and decryption cost CPU on every read and write. Hardware acceleration keeps it small, but capacity planning must count it.
Processing trust. Query execution requires plaintext at the selected host. Encryption at storage and transport boundaries cannot protect against that host misusing its authorized access.
Sharing. Giving another party access means exchanging keys, through public-key cryptography or delegated tokens. Access control has to be part of the encryption scheme, not bolted on above it.
Key custody in disguise. Some "bring your own key" offers require you to deposit the key with the provider. That is key escrow with extra steps. Read the custody model closely.
What to ask
Who decrypts? Identify every participant that can read plaintext. In Legra, that includes the selected query host. Who operates it, where does it run, and what access have you granted it?
Can the operator read the data under any circumstance? Ask it that way. Can support engineers? Can a court order? If the operator holds the key, the answer is yes.
What happens when you leave? Can you export your data and decrypt it on your own, or does the exit run through the provider's key service?
How is access enforced? Keys protect encrypted blocks from readers without decryption authority. An authorized host must also enforce permissions when serving requests. Ask about both boundaries, and about what happens when access is revoked. Revocation cannot erase information already retained by a reader.
Is the data model encrypted, or only the disk? Encrypting disk blocks is what most clouds do. Encrypting the facts themselves before they reach storage survives a change of infrastructure. The disk does not.
Try it in Legra
Start with workspace roles, invitations and access when deciding who should be able to use a dataset.