Cryptographic Key Management in Hybrid Cloud
Cibersegurança · 2 min
Articles by Luís Carvalho
Encryption only protects when keys are well-governed. Learn how to structure responsibilities, rotation, custody, and auditing in hybrid cloud.
TL;DR
- Key management should be treated as a governance process, not just a technical configuration.
- Hybrid cloud demands clear decisions on key custody, residency, rotation, access, and recovery.
- KMS, HSM, BYOK, and HYOK solve different problems and should be chosen based on risk and operating model.
- Auditing, segregation of duties, and recovery plans are as relevant as the encryption algorithm.
Why the key is the true control point
In many security programs, encryption is approved as a requirement, but key management is scattered across teams, vendors, and platforms. In hybrid cloud, this fragility is more visible: data in on-premises infrastructure, SaaS services, backups, and cloud workloads can depend on different custody models. The central question is no longer just “are the data encrypted?” and becomes “__who can use, recover, revoke, and audit the keys__?”.
Custody, residency, and responsibility
The organization must distinguish three decisions. The first is custody: are keys under the provider's control, brought by the company via BYOK, or do they remain outside the platform via HYOK? The second is residency: where are keys created, stored, and processed? The third is operational responsibility: who approves access, performs rotations, and responds to incidents? These decisions must be aligned with the [hybrid and multicloud strategy](/pt/solucoes/cloud), avoiding different policies for each project.
KMS, HSM, BYOK, and HYOK are not equivalent
A key management service, or "*KMS"*, simplifies creation, storage, rotation, and control of use. A "*Hardware Security Module"* adds specialized physical and logical protection for cryptographic material, allowing cryptographic operations to be executed and keys to be protected in a dedicated, controlled environment. "*BYOK"* allows importing keys created outside the platform, while "*HYOK"* keeps the key under external control. The choice must consider data criticality, vendor dependence, audit requirements, and internal operational capability.
Daily operation: rotation, access, and evidence
Key governance fails when it relies on informal knowledge. It is recommended to define owners, rotation policies, revocation procedures, segregation of duties, and usage logs. Integration with identity, monitoring, and incident management should also exist. This discipline complements related topics, such as [digital certificate management](/pt/blog/gestao-de-certificados-digitais-evitar-falhas), but it is not to be confused with them: certificate management deals with the lifecycle of digital certificates and associated trust, while key management covers the protection, use, rotation, recovery, and revocation of cryptographic material.
Continuity and recovery without creating new risks
A lost key can render legitimate data unrecoverable; an overly exposed key can compromise confidentiality. Therefore, recovery processes must be tested, documented, and limited to authorized functions. In architectures with confidential computing, key management becomes even more relevant because data protection in use depends on a consistent chain of trust. This point should be evaluated in conjunction with decisions about [confidential computing in hybrid cloud](/pt/blog/confidential-computing-cloud-hibrida).
Conclusion
Cryptographic key management is an architectural, governance, and risk decision. In hybrid cloud, it's not enough to enable default encryption: it's necessary to know who controls the keys, how they are used, when they are changed, how they are audited, and how they can be recovered. A simple, documented, and tested model can reduce hidden dependencies and improve trust in the platforms that support critical data.