A managed database proposal offers customer-managed encryption keys. The buyer reads customer-managed as meaning the whole database runs under the customer’s administration. The words describe an important control, but not that complete operating arrangement.
Managing a key and operating the database are separate responsibilities. A database selection should identify both, along with the service that operates the key-management infrastructure.
This distinction helps organizations describe the control they need precisely. It avoids rejecting a useful managed-service option for the wrong reason or accepting it under an assumption of infrastructure ownership it does not provide.
Understand the managed-key example
AWS KMS documentation describes customer-managed keys as keys customers create, own, and manage in their account, including policies and lifecycle choices. It also notes that individual AWS services differ in their support for key options.
The KMS overview identifies KMS itself as an AWS-managed service. The customer can therefore control important key decisions within a service it does not operate as a self-hosted key-management installation.
This is a concrete service example. It should not be generalized into identical custody, deployment, or control arrangements for every key-management product, including external key-store designs.
List the controls separately
The organization may care about approving key use, controlling key lifecycle, operating database hosts, authorizing database administrators, or choosing where the service runs. These are related requirements, but they should not be combined into one vague data-control checkbox.
Consider a hypothetical company that requires its security team to approve changes to a key policy. It may still prefer a provider to operate the database. Another company may require its own team to operate the database infrastructure as well. Those preferences lead to different evaluations.
The question is what the proposed arrangement actually assigns to each party. A key label does not answer who performs upgrades, manages host access, or operates recovery procedures.
Compare OceanBase deployment routes against the actual requirement
OceanBase Enterprise documents a customer-operated route on the organization’s infrastructure. This is a concrete reason to evaluate it when infrastructure operation and application continuity are part of the requirement.
OceanBase Cloud represents a managed-service route whose actual encryption and operating options should be assessed for the selected service. This article does not establish a particular KMS integration or customer-key feature for every OceanBase Cloud arrangement.
The comparison should distinguish the controls the organization needs from the implementation that supplies them. Neither self-hosting nor a key-management feature independently establishes the entire security outcome.
| Control question | Evidence to request | Responsibility to identify |
|---|---|---|
| Who controls key policy? | The selected key arrangement and permissions | The key owner and approving team |
| Who operates the key service? | The service or infrastructure model | Provider or customer operating team |
| Who operates the database? | The actual deployment and administration model | Database service and host responsibilities |
| Who can use application data? | The selected application and database access rules | The relevant data-access owners |
| Who maintains recovery? | The actual database and key dependencies | The teams responsible for keeping the path usable |
This framework does not prescribe changing or disabling a production key. It asks the proposal to explain the chosen responsibilities before the organization commits to the arrangement.
Evaluate a change across both operating teams
Use a representative planned change and identify who approves it, who implements it, and which application dependencies must be checked. The key team and database team should be able to explain their respective roles without assuming the other owns the entire process.
Review how the selected recovery procedure depends on the key arrangement. A database plan and a key plan can each look complete in isolation while leaving an unclear handoff between their operators.
Keep ordinary data access separate from key administration. The organization should understand which controls authorize its application users and database operations, rather than assume key ownership alone defines every use of decrypted data.
Also compare ongoing work. Self-hosting brings responsibilities that a managed service may perform, while customer-managed keys introduce decisions the customer must maintain. The operating estimate should account for the actual arrangement rather than count every customer-control label as the same work.
If provider exit is an objective, review that path separately too. Identify how exported information would be read and protected at the destination under the chosen design. Control of a key does not independently establish portable data formats or a completed migration procedure.
Choose the control boundary deliberately
Customer-managed keys can be a valuable part of a managed deployment. A customer-operated database can be valuable when infrastructure control and the selected application requirements justify that responsibility.
OceanBase and alternative database routes should be assessed against the controls the organization actually needs, with the chosen key service and database service described separately.
The stronger recommendation says who controls the key, who runs the infrastructure, and who operates the application. That is more precise than using customer-managed as a shortcut for self-hosted.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.