collaborative PP-Module for Database-as-a-Service (DBaaS)

FCS_CKM_DBAAS_EXT.1.1 The TSF shall support customer-controlled master encryption keys using one or more of the following mechanisms: [selection: customer-generated master keys imported into the TOE through a trusted channel specified by the DBMS Cryptographic Functions Module; externally managed master keys accessed through a key management service interface where plaintext master key material is not exported to the TOE; customer-controlled key references or key handles that permit the TOE to perform authorized cryptographic operations without exposing plaintext master key material to service provider administrators; customer-authorized Master Key establishment through ML-KEM with an authenticated external entity, using the role-specific key-encapsulation and key-derivation requirements of the DBMS Cryptographic Functions Module].

FCS_CKM_DBAAS_EXT.1.2 The TSF shall not provide an interface by which a service provider administrator can view, export, or recover plaintext customer-controlled master key material.

FCS_CKM_DBAAS_EXT.1.3 The TSF shall prevent access to protected database data no later than [assignment: key-state enforcement interval] after authorized use of the applicable customer-controlled master key is revoked, unavailable, or denied, except for data that remains available through an explicitly documented and evaluated recovery mechanism whose use requires authorization by the tenant or an agent under the tenant’s control.

Application Note: This requirement is intended to address DBaaS customer-controlled key models such as BYOK, HYOK, external KMS integration, or equivalent key-reference mechanisms. The recovery-mechanism exception in FCS_CKM_DBAAS_EXT.1.3 cannot be completed by provider-held escrow or any mechanism the service provider can exercise unilaterally: a recovery path usable without tenant authorization would reintroduce exactly the disclosure this component excludes (T.KEY_DISCLOSURE_TO_PROVIDER_ADMIN). Use of a recovery mechanism is an auditable event (see the auditable-events table). Where the documented recovery mechanism is implemented as a restore from backup — the common case, using a retained older key version — it is the same operation addressed by FDP_BKP_EXT.1: a single use of the mechanism shall satisfy both the tenant-authorization constraint of this component and the restore authorization and tenant binding of FDP_BKP_EXT.1. This requirement does not require the TOE to protect against arbitrary modification of the Trusted Platform or cloud control plane. If the TOE stores, caches, wraps, transforms, or re-exports key material after receipt, the ST shall identify that behavior and the applicable DBMS-specific and Catalogue-derived key protection components in the DBMS Cryptographic Functions Module.

+ The key-state enforcement interval assignment in FCS_CKM_DBAAS_EXT.1.3 accommodates the key-state detection and availability behavior of production managed database services: external key-provider state is typically detected by periodic polling rather than synchronous notification, and services commonly document a bounded grace period during which cached key material remains in use when the external key provider is unreachable, so that a transient key-service or network fault does not immediately take down the database. Production DBaaS offerings document detection intervals on the order of minutes and unreachability grace periods on the order of hours. The ST author shall complete the assignment with the maximum interval between a key-state change at the external key provider and TSF denial of access to protected database data, covering both worst-case detection latency and any documented unreachability grace period, and covering the lifetime of any cached key material identified under the caching disclosure above. The completed interval shall be a fixed, documented bound: an interval that is indefinite, that is extensible by service provider action, or that resets on continued data access does not satisfy the requirement. Expiration of the interval and the resulting transition to the key-unavailable enforcement state are auditable events (see the auditable-events table). The interval bounds enforcement latency only; it does not weaken FCS_CKM_DBAAS_EXT.1.2, which admits no interval during which plaintext customer-controlled master key material may be exposed to a service provider administrator.

+ The mechanisms selected in FCS_CKM_DBAAS_EXT.1.1 couple to the Key Origin selection in the Crypto Module’s FCS_CKM_EXT.1.1: customer-generated master keys imported into the TOE correspond to "Imported from External Entity"; externally managed master keys and customer-controlled key references correspond to "Externally Managed"; and customer-authorized ML-KEM establishment corresponds to "Established through Key Encapsulation". The ST shall complete FCS_CKM_EXT.1.1 with the corresponding selection, and every external origin includes FDP_ITC_EXT.1 (Trusted Channel for Key Import, External Key Management, and Key Establishment).

+ For the KEM-established model, the ST shall identify whether the TOE performs encapsulation, decapsulation, or both; shall include FCS_CKM.1/KEM only for TOE-performed ML-KEM.KeyGen; and shall identify any operation performed by an external KMS or customer-controlled service as outside the TOE boundary. The ML-KEM shared secret is not itself the customer-controlled Master Key: the Crypto Module’s FCS_CKM.5 derives the Master Key with a context that binds the customer, service instance, key purpose, and applicable establishment transaction. Selection of this mechanism is permitted only where the customer or its authorized external entity retains a control whose revocation, unavailability, or denial causes the TSF to enforce FCS_CKM_DBAAS_EXT.1.3 within the assigned interval. A one-time KEM exchange after which the provider can use the derived Master Key indefinitely without customer authorization does not satisfy this customer-controlled model.

FDP_RIP.1.1/DBaaS The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to a different tenant for the following resources: [selection: memory, buffer cache, temporary storage, query work areas, diagnostic structures, [assignment: other shared DBMS resources]].

Application Note: In shared DBaaS architectures, this requirement addresses residual tenant data in DBMS-managed resources that may be reallocated across tenant contexts. The ST should describe whether tenant data can be present in shared memory, buffer cache, temporary storage, query work areas, diagnostic structures, or other shared DBMS resources, and how such resources are cleared, reinitialized, or access-controlled before reuse. This iteration refines the Base PP FDP_RIP.1 for cross-tenant resource reuse in a multi-tenant managed service.

FDP_ACC.1.1/DBaaS The TSF shall enforce the Tenant Isolation SFP on [tenant subjects, tenant data objects, tenant metadata objects, tenant audit records, and all operations among tenant subjects and those objects].

Application Note: This SFR is CC:2022 Part 2 FDP_ACC.1 (Subset access control), iterated for the Tenant Isolation SFP. Subset access control is claimed deliberately: the Tenant Isolation SFP governs tenant-scoped subjects, objects, and operations, while subjects and objects outside its scope — including the Base PP’s users and objects and provider-side automation — are governed by the access control SFPs of the Base PP as claimed in the composed ST. A complete-access-control claim (FDP_ACC.2) is not made, because completeness across all TSF-controlled subjects and objects is a property of the composed ST rather than of this module in isolation.

FDP_ACF.1.1/DBaaS The TSF shall enforce the Tenant Isolation SFP based on the following security attributes: [tenant identifier, user identifier, service role, object owner, object tenant identifier, object type, and operation].

FDP_ACF.1.2/DBaaS The TSF shall enforce the following rules:

FDP_ACF.1.3/DBaaS The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects].

FDP_ACF.1.4/DBaaS The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects].

Application Note: The ST should identify the tenant boundary used by the TOE, such as databases, pluggable databases, schemas, namespaces, tablespaces, tenant identifiers, accounts, or other DBMS constructs. If an evaluated cross-tenant sharing mechanism is claimed, the ST shall describe the authorization model, audit behavior, and limits of that mechanism.

FRU_RSA.1.1/DBaaS The TSF shall enforce maximum quotas of the following resources: [selection: CPU, memory, I/O bandwidth, storage, sessions, query concurrency, workload queues, [assignment: other DBMS-managed resources]] that [individual tenants, as defined groups of users] can use [selection: simultaneously, over a specified period of time].

Application Note: This SFR is CC:2022 Part 2 FRU_RSA.1, iterated for tenant resource governance. The Part 2 assignment of controlled resources is narrowed to the selection shown; the subject selection is completed by treating each tenant as a defined group of users. It does not require the TOE to enforce infrastructure-level resource controls provided solely by the Trusted Platform unless those controls are included in the TOE boundary and claimed in the ST.

FRU_RSG_EXT.1.1 The TSF shall [selection: terminate, throttle, queue, reject, [assignment: other enforcement action]] operations that exceed the resource quotas enforced by FRU_RSA.1/DBaaS.

Application Note: CC Part 2 FRU_RSA.1 requires quota enforcement but does not specify the action taken when a quota is exceeded; this extended component specifies that action so it can be evaluated.

FDP_BKP_EXT.1.1 The TSF shall not provide an interface by which a service provider administrator can restore or export protected tenant data from a backup in plaintext without authorized use of the applicable customer-controlled master key.

FDP_BKP_EXT.1.2 The TSF shall bind restored tenant data to the originating tenant identifier such that a restore operation does not place tenant data outside the Tenant Isolation SFP.

Application Note: This requirement addresses backup and restore as a disclosure vector specific to provider-operated DBaaS, where backups are commonly created, stored, and restored by provider tooling. Backups of protected tenant data inherit data-at-rest protection from FDP_DAR_EXT.1 of the mandatory DBMS Cryptographic Functions Module: because protected data is encrypted at rest under the customer-controlled key hierarchy, its backup is encrypted under the same hierarchy, and this SFR does not restate that protection. This SFR instead specifies the requirements particular to the backup and restore path: that the TOE provides no interface for a service provider administrator to obtain plaintext tenant data through restore or export without authorized key use, and that restore preserves tenant isolation. If the TOE delegates backup storage to an external object storage or backup service, the ST shall identify whether the restore authorization and tenant binding are provided by the TOE or by an external service addressed through OE.EXTERNAL_SERVICES; the data-at-rest protection of externally stored backups is addressed by FDP_DAR_EXT.1. A restore that serves as the documented recovery mechanism of FCS_CKM_DBAAS_EXT.1.3 is additionally subject to that component’s tenant-authorization constraint; where the two coincide, the ST shall describe them as a single mechanism.

FIA_USB.1.1/DBaaS The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: [tenant identifier, user identifier, and service role].

FIA_USB.1.2/DBaaS The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of users: [a subject shall bind to the tenant identifier of the authenticating user or service account before the subject performs tenant-scoped operations].

FIA_USB.1.3/DBaaS The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of users: [a tenant identifier associated with a subject shall not be changed by tenant-controlled session parameters, connection attributes, or request inputs except through an evaluated mechanism identified in the ST].

Application Note: This SFR is an iteration of CC:2022 Part 2 FIA_USB.1, completed for tenant-context binding in a multi-tenant managed service. This binding is critical for the database engine to enforce the logical isolation policies defined in FDP_ACC.1/DBaaS and FDP_ACF.1/DBaaS. It is independent of the Base PP’s optional extended component FIA_USB_EXT.2; if the ST also claims FIA_USB_EXT.2, the tenant attributes defined here apply to that component’s binding rules as well.

+ Subjects need not act on behalf of a human user. Where the automated autonomous management logic role is selected in FMT_SMR.1/DBaaS, a subject acting on its behalf within a tenant context binds the tenant identifier of the affected tenant under the same rules, so that autonomous actions remain inside the Tenant Isolation SFP and their audit records remain tenant-attributable.

FMT_SMR.1.1/DBaaS The TSF shall maintain the roles: Tenant User, Tenant Administrator, Service Provider Administrator, and [selection: automated autonomous management logic, [assignment: other roles]].

FMT_SMR.1.2/DBaaS The TSF shall be able to associate users with roles.

Application Note: This iteration defines the DBaaS-specific role model on which the management restrictions in the FMT_MOF.1/DBaaS iterations and the access-control rules in FDP_ACF.1/DBaaS depend. The Tenant Administrator manages tenant data and tenant-level configuration only to the extent permitted by the evaluated configuration; the Service Provider Administrator operates the managed service but is excluded from the customer-controlled key and tenant-data access paths constrained by this module.

+ Automated autonomous management logic, where selected, is a subject class rather than a human role: its actions within a tenant context carry tenant attribution under FIA_USB.1/DBaaS, its audit records identify it as the acting subject (see the auditable-events table), and where it acts on a tenant’s service instance those records are visible to the affected tenant in the service event stream.

+ The role names Tenant User, Tenant Administrator, and Service Provider Administrator are module-level labels for scopes of authority, not required TOE role names. The TSF is not required to maintain roles under these names. The ST shall map each label to the TOE role, privilege set, group, or account class that realizes it in the TOE’s own terminology; one label may be realized by several TOE roles, and several TOE roles may share a label. The mapping shall preserve the authority boundaries the labels denote: no mapping may assign a single TOE role both Service Provider Administrator authority and tenant-scoped authority in a way that vacates the separation enforced by the FMT_MOF.1/DBaaS iterations, FDP_ACF.1/DBaaS, or FCS_CKM_DBAAS_EXT.1. Throughout this module and its Supporting Document, a reference to one of these role names means the TOE role or roles the ST maps to that label.

FMT_SMF.1.1/DBaaS The TSF shall be capable of performing the following management functions:

Application Note: The management functions defined here are the functions on which FCS_CKM_DBAAS_EXT.1, FRU_RSA.1/DBaaS, FRU_RSG_EXT.1, FAU_SEL.1/DBaaS, and the FMT_MOF.1/DBaaS iterations depend. The roles authorized to perform each function are defined by FMT_SMR.1/DBaaS and constrained by the FMT_MOF.1/DBaaS iterations.

FMT_MOF.1.1/DBaaS-Disable The TSF shall restrict the ability to [disable] the functions [audit generation and data-at-rest encryption for protected tenant data] to [no role in the evaluated configuration].

Application Note: No role, including the Service Provider Administrator, may disable the identified functions in the evaluated configuration. CC Part 2 FMT_MOF.1 has a single element; the disable restriction and the provider-role restriction are therefore expressed as two iterations rather than as two elements of one component.

FMT_MOF.1.1/DBaaS-Modify The TSF shall restrict the ability to [modify the behaviour of] the functions [resource governance policies, patching and updates, audit export configuration, and [assignment: other DBaaS security functions]] to [selection: Service Provider Administrator, automated autonomous management logic, [assignment: other authorized role]].

Application Note: The Tenant Administrator is excluded from the provider-operated functions identified in this requirement. Tenant administrators may manage tenant data and tenant-level configuration only to the extent permitted by the evaluated configuration and the ST.

FAU_SEL.1.1/DBaaS The TSF shall be able to select the set of events to be audited from the set of all auditable events based on the following attributes: [tenant identifier, user identifier, service role, object identifier, and event type].

Application Note: This iteration of the Base PP’s FAU_SEL.1 adds tenant-scoped audit selection in a multi-tenant managed service. Restriction of audit record queries to the owning tenant is not audit pre-selection; it is enforced as an access-control rule by FDP_ACF.1.2/DBaaS (tenant subjects access only audit records associated with the same tenant identifier).

FAU_STG.2.1/DBaaS The TSF shall protect the stored audit records in the audit trail from unauthorised deletion, including deletion attempted by a tenant administrator through TOE interfaces.

FAU_STG.2.2/DBaaS The TSF shall be able to [prevent] unauthorised modifications to the stored audit records in the audit trail, including modifications attempted by a tenant administrator through TOE interfaces.

Application Note: This SFR is CC:2022 Part 2 FAU_STG.2 (Protected audit trail storage), iterated with the modification selection completed as "prevent" and refined to state explicitly that tenant administrators are not authorized subjects for modification or deletion of TOE-generated audit records: the TOE provides no tenant-facing interface for those operations. If audit records are exported to an external logging or storage service, the ST shall identify whether the export mechanism, external service, or both are included in the TOE. External services relied upon for storage immutability are addressed by OE.EXTERNAL_SERVICES unless claimed as TOE functionality.

FPT_TUD_DBAAS_EXT.1.1 The TSF shall apply updates to the DBMS service software through the service provider’s authorized update process using [selection: uniform rolling deployment to all service instances, deployment with tenant-configurable deferral within [assignment: maximum deferral period], deployment within tenant-selectable maintenance windows].

FPT_TUD_DBAAS_EXT.1.2 The TSF shall verify the authenticity and integrity of DBMS service software updates by digital signature before the updated software is placed into service, without requiring tenant administrator intervention.

FPT_TUD_DBAAS_EXT.1.3 The TSF shall provide tenants the ability to determine the version or revision identifier of the DBMS service software currently serving the tenant.

Application Note: Conformance to this component means the service provider stands behind a defined update mechanism; the deployment model of that mechanism is declared through the selection in FPT_TUD_DBAAS_EXT.1.1 rather than prescribed. A continuously deployed service that maintains a single live service target conforms by selecting uniform rolling deployment and identifying the deployment artifacts to which signature verification applies. The signature envelope format is not constrained: X.509 certificate-based signatures, OpenPGP signatures, and detached signatures over deployment artifacts are all acceptable, provided the signature algorithm and its hash are completions allowed by FCS_COP.1/SigVer in the mandatory DBMS Cryptographic Functions Module and the verification key is integrity protected. Hash algorithms outside the allowed completions (for example, SHA-1) cannot be claimed. Certificate path validation is in scope of the Functional Package for X.509 Certificates [[X509_FP]] only when certificates are used.

+ Update pipeline mechanics may reside partly in the operational environment, but the update verification and tenant-facing version visibility required by this component are TSF behavior: the TSS shall describe the end-to-end update process, identify where signature verification occurs, and identify the TOE-side enforcement points. An ST in which update handling lies wholly outside the TOE boundary cannot complete this component and therefore cannot claim conformance to this PP-Module. The version or revision identifier of FPT_TUD_DBAAS_EXT.1.3 need not be a semantic version: a build identifier or rollout identifier satisfies the requirement, provided it unambiguously identifies the deployed service software for tenant change-management and support purposes.