TECHNICAL NOTEBOOK / Enterprise Security

Who Can Decrypt? Designing Access Control Around Encrypted Data

Follow an authorized document read to understand where application permissions, workload identity, HSM controls, authenticated context, and revocation fit around encrypted data.

JASON SARIWATING2026-11-0311 min read

Access ControlData EncryptionHSMKey ManagementApplication Security

A service can decrypt a document successfully and still return it to the wrong person.

Consider a fictional reporting portal. It stores encrypted documents for several organizations. A signed-in user requests a report, the backend retrieves its ciphertext, and a cryptographic service helps recover the plaintext. Every cryptographic operation succeeds. The failure occurs earlier: the backend never checks whether that user belongs to the organization that owns the report.

This is an architecture walkthrough, not a customer incident or production implementation. It follows one document read to separate business permissions from cryptographic permissions. The distinction matters whether the application uses a managed key service, an HSM-backed platform, or a combination of both.

Decide What the Encryption Protects

Encryption has to be evaluated at a specific boundary. Disk encryption can protect a removed drive; an authorized running application may still read the same data. Database encryption can protect stored files without preventing a privileged database session from querying plaintext. Application-level encryption changes where decryption happens, but the application that performs it becomes part of the trusted path.

OWASP's Cryptographic Storage guidance ties this choice to the threat model. There is no single encryption layer that answers every access question.

For the example portal, the design goal is narrower: a copied database should not be sufficient to read document contents, and a normal portal user should only receive documents that the application's policy permits. Those are separate acceptance criteria. I would test them separately rather than treating an encrypted database as proof of both.

The second criterion requires a decision about a user, a document and an action. A key being usable does not supply that decision.

Separate the User from the Workload

A user signs in to the portal. The backend, meanwhile, authenticates to the cryptographic service using its own workload identity. The key service may see the backend identity rather than the individual person at the browser.

That distinction creates two questions:

May this user read this particular document?
May this workload perform the required operation with the configured key?

The first belongs to the application's authorization policy. The second belongs to the cryptographic service and its access controls. Passing either check alone is insufficient for this design.

OWASP recommends least privilege, denial by default and permission checks on every request. A valid login establishes identity; it does not grant unrestricted access to every record the backend can reach.

For our portal, a service account that can decrypt every organization's records would have a large scope of access. I would document that scope explicitly and evaluate narrower identities, key policies or service boundaries where the operational requirements justify them. More keys or identities also create provisioning and recovery work; their presence alone does not prove tenant isolation.

Follow One Authorized Read

The normal read path for this example has six stages:

Validate the user's session
Load the document's trusted ownership metadata
Authorize this user, document and read action
Request the permitted cryptographic operation as the workload
Authenticate the encrypted payload before using plaintext
Return only the authorized result

The browser supplies a document identifier. The backend loads ownership and classification from trusted storage, evaluates the user's current access, then obtains the protected content through an approved path. It does not accept a request parameter such as tenant=other-company as proof that the user belongs to that tenant.

The decision and the content read must refer to the same document revision or equivalent consistent state. Otherwise, an ownership change between those steps could make the authorization decision stale. For this portal, that consistency rule would be part of the storage contract and concurrency tests.

Opaque identifiers can make enumeration harder, but they do not replace object-level checks. OWASP's IDOR prevention guidance explains why access must still be checked even when identifiers are difficult to guess.

The application also needs checks on alternate paths. A report download, export job and preview endpoint should not quietly use different ownership rules.

Write the Permission Matrix Before the Integration

For this fictional portal, I would begin with a small matrix. These are proposed permissions for the example, not default permissions of any HSM or cloud platform.

Identity	Intended capability	Capability deliberately excluded
Portal reader	Read assigned documents within the permitted organization	Read another organization's documents
Report writer	Submit new reports through the application	Export all historical reports
Runtime service	Perform the cryptographic operations needed by approved requests	Change key policy or destroy keys
Key administrator	Manage the approved key lifecycle	Read report contents merely by holding this role
Recovery operator	Execute an approved, scoped recovery procedure	Use recovery credentials for routine browsing

The matrix exposes questions that a successful decrypt test would miss. Does the writer need to read previous reports? Can an administrator grant themselves runtime permissions? Does a bulk export require additional approval? What happens when someone changes organizations?

Separating roles in a document is only a starting point. If one administrator can change every policy, impersonate the workload and read storage without oversight, the effective separation is weaker than the table suggests. The deployment review should evaluate the combined permissions, including indirect routes to access.

What the HSM Can Enforce

An HSM can enforce restrictions on the keys and operations it controls. For example, Entrust's nShield access-control documentation describes HSM-enforced key ACLs, including operation restrictions and authorization-token requirements.

Those controls do not automatically express the reporting portal's business rules. The application must still determine whether a particular document belongs to a permitted organization and whether the requested action is allowed.

There is another boundary to inspect: where the payload is decrypted. With application-side envelope encryption, a key service protects a data encryption key, while the application uses the recovered DEK to process the payload. Google's envelope-encryption documentation describes the DEK/KEK distinction and application-side workflow.

In that arrangement, the application handles plaintext and an unwrapped DEK temporarily. Saying that the wrapping key is hardware-protected does not mean the entire application is free of plaintext key material.

For the portal's design record, I would name each operation, its execution location, and the material returned to the caller. A reviewed diagram should make those boundaries visible instead of hiding them behind a single box labelled HSM.

Bind the Ciphertext to Its Intended Context

Suppose an envelope is copied from one document record to another. A robust format can authenticate stable context, such as an internal document reference or a purpose label, so that the reader can reject a mismatched envelope.

Provider details matter. AWS KMS supports encryption context for symmetric encryption keys, binds it to ciphertext, and can use it in policy conditions. The context is not confidential and can appear in CloudTrail logs. See the AWS KMS encryption-context documentation.

This is not a universal API feature with identical behavior across providers. Application payload AAD and a key service's wrapping context may be separate inputs with different scopes.

For the example portal, I would derive the expected context from trusted record metadata, not blindly replay whatever the request or envelope claims. A cryptographically valid context is still insufficient if the caller is allowed to choose another organization's context freely.

The context design would use non-sensitive values, a documented encoding and versioning rules. An identifier is not automatically safe for logs merely because it is not a password. Review what it reveals and who can read it.

Give the Runtime Its Own Credentials

The workload's credentials deserve a separate lifecycle from user sessions. A user logging out should not be confused with revoking the backend's access to the key service.

OWASP's Secrets Management guidance discusses scoped access, auditing and credential lifecycle management. Where the platform supports it, short-lived workload credentials can reduce dependence on long-lived secrets. They still require a trustworthy issuance path and appropriate permissions.

For our portal, I would keep development and production identities separate, avoid placing runtime credentials in source control, and test credential replacement with multiple application instances running. If an old instance continues using a retired credential, the resulting error should identify an operational problem without disclosing the credential itself.

Recovery credentials would have a different activation procedure and owner. An outage should not encourage engineers to copy an administrator's identity into the ordinary service configuration.

Account for Caches and Revocation

A permission change may not immediately remove every capability already issued to a running process.

The AWS Encryption SDK caching documentation describes how cached data keys can satisfy operations without another key-service request, and why caching needs explicit security thresholds. The operational implication is that revoking remote permission may not invalidate material already held locally.

For the portal, I would map several independent lifetimes: the user session, cached authorization decisions, workload credentials, cached DEKs and any cached plaintext responses. A revocation test would measure the actual behavior of each one.

The proposed policy would specify whether a user removal must affect the next request immediately or within a documented window, then implement invalidation or revalidation accordingly. Short cache durations reduce some exposure, but they are not a substitute for defining that requirement.

No revocation mechanism can recall plaintext that an authorized recipient has already copied. That limit should inform which fields are returned and whether bulk retrieval is necessary.

Deny Safely and Keep Useful Evidence

When the example portal cannot establish permission, it should return no plaintext. An unavailable authorization dependency must not silently turn into an allow decision.

Receive the document request
Evaluate identity and authorization
A denial or required dependency failure stops the read
Record a non-sensitive outcome and correlation reference
Return a bounded response without document contents

This is the failure branch, not a second path to decryption. The response can distinguish an operational outage from an access denial where appropriate, but it should not expose sensitive document metadata to an unauthorized caller. Internal diagnostics can be more specific than public error text.

OWASP's Logging guidance recommends useful security-event context while excluding secrets such as access tokens, passwords and encryption keys. For this portal, I would record a correlation reference, policy outcome, permitted resource reference, workload identity and a safe error category. Log access would itself be restricted.

I would not log decrypted report bodies, raw authorization headers, unwrapped DEKs or request dumps containing sensitive fields. A debug switch should not create a second, unprotected copy of the application database.

Test Denials Alongside Successful Reads

These tests belong in an isolated environment with synthetic documents and identities. The matrix below is a proposed test plan for the example portal.

Scenario	Expected evidence
An assigned reader opens a permitted report	Correct content, application authorization event and matching cryptographic activity
A reader requests another organization's document	No plaintext; denial before the document-decryption operation
A caller changes an organization field in the request	Trusted ownership remains authoritative
A permitted request reaches a workload without key permission	Controlled failure; no fallback to broader credentials
A runtime identity attempts key administration	The operation is rejected by the configured policy
Ciphertext or authenticated context is altered	Authentication fails and no partial plaintext is returned
Document ownership changes during a read	Consistency rules prevent a stale decision from authorizing the wrong revision
User access is removed while caches are populated	Behavior matches the documented revocation requirement
The authorization or key service is unavailable	Bounded failure; no plaintext fallback or unbounded retry loop
A bulk export uses a separate execution path	The same intended object and action permissions still apply

I would retain evidence of the denied cases, not only screenshots of successful decryption. The useful question is which layer rejected the request and whether later layers remained unused where the design required them to.

Review the Complete Read Path

Before approving this portal's design, I would want an engineer to trace a document read from the browser to its final response. The explanation should identify the user, the workload, the ownership decision, the cryptographic boundary and every place plaintext may exist.

Encryption protects data under specified conditions. Access control determines who can ask the running system to recover and disclose it. A design needs both, plus a way to test what happens when one of the required decisions fails.

For the related lifecycle problem, continue with Key Rotation Without Losing Access to Your Data. The Data Protection Lab illustrates cryptographic transformations; it is a browser-only educational demo, not an implementation of the multi-user authorization system described here.