Cross-Agency Case Search Versus Tenant Key Custody
A shared-services provider is building a multi-tenant case-management platform for 12 regulatory agencies. Tenant data must be encrypted with customer-managed keys held in each agency's own key service, and each agency's data must remain in its own region. A new statutory requirement allows cross-agency case referral, which requires investigators to search case text across agencies. The performance budget is 300 ms for a case search. The current design encrypts each tenant database with a separate key and cannot search across tenants without decrypting. The steering committee asks for a design that satisfies all three: key custody, residency, and cross-agency search. The budget is fixed and delivery is 10 months out. Two agencies have already stated they will not accept a shared search index.
1. How should the security engineer handle the conflict among the three requirements?
Read the worked answer
The conflict is real and should not be resolved silently by weakening encryption or residency. The engineer should first separate the requirements by source and authority: key custody and residency are policy or contractual obligations; cross-agency search is a statutory capability. Then determine whether the statute requires full-text search across all agencies or only search over cases that have been formally referred. That distinction changes the design.
The engineer should present the steering committee with options and their risk: a shared encrypted index with tenant-controlled keys, tokenized search with content fetched from the tenant store after authorization, a brokered referral model in which only referred cases are decrypted and indexed, or a federated query that sends limited requests to each tenant. Each option has different latency, cost, and residual risk. The two agencies that reject a shared index constrain the solution and should be engaged directly.
The committee, not the engineer alone, must decide whether to seek a policy exception, change the statutory interpretation, or accept higher cost. The decision should be recorded with rationale, residual risk, and affected agencies. The worst outcome is a design that appears to meet all three requirements while actually allowing the provider to read tenant plaintext.
2. Translate the policy statements into verifiable security requirements with acceptance criteria.
Read the worked answer
Each policy statement needs a measurable requirement and a verification method. For key custody: tenant data at rest shall be encrypted with keys held in the agency's key service; the provider shall not have persistent access to plaintext or key material; key revocation shall take effect within a defined time, for example 15 minutes; all key use shall be logged and visible to the agency. Verification is by design inspection, key-management test, and audit-log review.
For residency: tenant data, backups, and search indexes shall remain in the agency's designated region; cross-region replication shall be prohibited unless explicitly authorized; data location shall be attested and auditable. Verification is by configuration inspection, provider attestation, and sample testing.
For cross-agency search: an investigator shall retrieve only cases for which a referral or authorization exists; search results shall not expose plaintext from non-referred agencies; search latency shall be at most 300 ms at the 95th percentile under a defined load; every cross-agency query shall be logged with requester, tenant, and legal basis. Verification is by test with synthetic data, access-control testing, and performance measurement. These requirements expose the trade-off: if search must operate over plaintext, either key custody or the no-shared-index constraint must change.
3. Recommend an architecture and explain the trade-offs the steering committee must accept.
Read the worked answer
A defensible architecture is a referral-brokered model with tokenized search. Each tenant store remains encrypted under the agency's key in its region. When a case is referred, the platform creates a referral record with explicit authorization and a time-bound grant. A shared index contains only tokens, case identifiers, agency identifiers, dates, and non-sensitive metadata; it does not contain plaintext. Search returns candidate identifiers, and the platform fetches and decrypts content only from tenants with a valid referral, using the agency key service. Federated search can supplement this for agencies that refuse any shared index.
The trade-offs are latency, cost, and scope. Fetching and decrypting after search will likely exceed 300 ms for broad queries; the committee may need to accept a higher budget for cross-agency searches or restrict them to metadata first. Tokenization reduces search richness, so investigators may not get full-text search across unreferred cases. Agencies that refuse the shared index require a federated connector, which adds operational complexity. The provider's operational access must be constrained, and break-glass access must be logged and approved.
The steering committee should approve the model, the residual risk, and any policy exception needed. The security engineer should document the decision in the security architecture, update the requirements traceability, and define tests for authorization bypass, key revocation, and residency. If the committee insists on full-text search over all tenants with provider-held keys, that is a different risk decision and should be recorded as such.