8.1 OCI Vault, Key Management & Data Encryption

8.1 OCI Vault, Key Management & Data Encryption

[!NOTE] Exam Blueprint Scope: In the OCI Foundations Associate (1Z0-1085-26) examination, data security and cryptography are core pillars of Domain 3 (Security Services). Candidates must master the OCI Vault service architecture, Hardware Security Module (HSM) compliance standards, envelope encryption key hierarchies, the operational differences between Oracle-managed and customer-managed keys (including BYOK), Secrets Management, and pervasive encryption defaults across OCI storage and networking services.

Data security in modern enterprise cloud architectures rests on the foundational principles of confidentiality, integrity, and non-repudiation. As organizations migrate mission-critical databases, financial transactions, and regulated user records to the cloud, securing digital assets against unauthorized interception, hardware theft, and administrative misconfiguration becomes paramount. In Oracle Cloud Infrastructure (OCI), cryptographic data protection is not an optional add-on—it is a pervasive, built-in architectural primitive enforced at every layer of the technology stack.

At the epicenter of OCI's cryptographic framework is OCI Vault, a managed, highly available, centralized key management and secrets storage service designed to protect sensitive credentials and manage the lifecycle of encryption keys.

---

OCI Vault Service Architecture & FIPS 140-2 Level 3 HSMs

OCI Vault (formerly known as OCI Key Management Service or KMS) provides centralized control over the cryptographic keys that protect your data and the secret credentials you use to secure access to your applications and databases.

Hardware Security Modules (HSMs)

To satisfy the most stringent global compliance and regulatory mandates (such as PCI-DSS, HIPAA, FedRAMP, and GDPR), OCI Vault is backed by dedicated, enterprise-grade Hardware Security Modules (HSMs):

• FIPS 140-2 Security Level 3 Certification: OCI Vault HSMs are certified to the United States Federal Information Processing Standards (FIPS) 140-2 Level 3. This standard validates that the physical hardware contains tamper-evident coatings, physical intrusion detection barriers, and zeroization mechanisms that immediately erase cryptographic material if physical tampering is detected.
• Cryptographic Isolation: Cryptographic keys generated inside an HSM reside exclusively in the protected memory of the hardware coprocessor. Plaintext key material can never be exported or viewed by human operators, software processes, or Oracle cloud engineering personnel.
• Hardware-Executed Operations: All cryptographic operations involving Master Encryption Keys (such as encrypting a data key, decrypting a data key, or generating digital signatures) take place directly inside the HSM silicon itself, ensuring that raw keys are never exposed to host operating system memory.

Vault Deployment Tiers

OCI offers two deployment options for Vault to accommodate diverse architectural requirements and budgets:

1. Default Vault (Shared HSM):

   • Provides multi-tenant Hardware Security Module partitions where multiple customers share the underlying physical HSM appliances, isolated by strict logical and cryptographic boundaries.
   • Delivers standard enterprise key management, secrets management, and automated high availability across Availability Domains.
   • Carries no hourly vault instance fee (customers pay only for the storage of active key versions and secret API operations), making it the recommended choice for standard enterprise workloads.

2. Virtual Private Vault (Dedicated HSM):

   • Allocates dedicated, single-tenant physical HSM partitions exclusively to a single customer tenancy.
   • Delivers dedicated cryptographic processing cores and isolated memory buffers, giving deterministic and consistently higher cryptographic transactions per second. Note for the exam: Oracle publishes a 99.9% availability SLA and a 99.99% availability service level objective (SLO) for key management, so a Virtual Private Vault buys isolation and predictable throughput rather than a higher contractual SLA.
   • Essential for large financial institutions, healthcare providers, and sovereign government agencies whose compliance frameworks legally mandate physically dedicated cryptographic hardware.

---

Envelope Encryption & The Key Hierarchy

A central design challenge in cloud cryptography is balancing extreme security with high performance. Encrypting large datasets (such as multi-terabyte database volumes or object storage buckets) directly inside an HSM is technically impractical because HSM hardware is optimized for key generation and small payload operations; passing gigabytes of raw data across the network into an HSM would introduce catastrophic performance bottlenecks.

OCI solves this challenge through an industry-standard cryptographic pattern known as Envelope Encryption.

+-----------------------------------------------------------------------------------------+
|                         OCI ENVELOPE ENCRYPTION ARCHITECTURE                            |
+-----------------------------------------------------------------------------------------+
|                                                                                         |
|   +---------------------------------------+                                             |
|   |           OCI Vault (HSM)             |                                             |
|   |                                       |                                             |
|   |   +-------------------------------+   |                                             |
|   |   | Master Encryption Key (MEK)   |   | <--- FIPS 140-2 Level 3 Hardware Security    |
|   |   | (Never leaves the HSM memory) |   |      Module Boundary                        |
|   |   +---------------+---------------+   |                                             |
|   +-------------------|-------------------+                                             |
|                       |                                                                 |
|           Protects / Encrypts / Decrypts                                                |
|                       |                                                                 |
|                       v                                                                 |
|       +-------------------------------+                                                 |
|       |   Data Encryption Key (DEK)   | <--- Generated by Vault for specific service    |
|       +---------------+---------------+                                                 |
|                       |                                                                 |
|               Encrypts Raw Data                                                         |
|                       |                                                                 |
|                       v                                                                 |
|       +-------------------------------+                                                 |
|       |   Raw Customer Data Payload   | <--- Block Volume, Object Storage, Database TDE |
|       +-------------------------------+                                                 |
+-----------------------------------------------------------------------------------------+

The Two-Tier Key Hierarchy

Envelope encryption establishes a clean two-tier key hierarchy:

1. Master Encryption Key (MEK):

   • The MEK (also known as the Key Encryption Key or KEK) is created and stored permanently inside the OCI Vault HSM.
   • Its sole operational purpose is to encrypt and decrypt Data Encryption Keys (DEKs).
   • MEKs support multiple standard cryptographic algorithms: AES (Advanced Encryption Standard) with key lengths of 128, 192, or 256 bits for symmetric operations; RSA (2048, 3072, or 4096 bits) for asymmetric key operations; and ECDSA (Elliptic Curve Digital Signature Algorithm using NIST curves P-256, P-384, or P-521) for digital signatures.

2. Data Encryption Key (DEK):

   • The DEK is a dynamic, temporary symmetric encryption key (AES-256) used to encrypt and decrypt the actual raw customer data payload (such as blocks on a disk volume or objects in a storage bucket).
   • DEKs are generated by Vault on demand at the request of an authorized OCI service.

The Step-by-Step Envelope Encryption Workflow

To understand how envelope encryption functions in practice during a data write operation:

1. Request: An OCI storage service (such as OCI Block Volume) needs to encrypt a new volume. It invokes OCI Vault via internal API, requesting a new Data Encryption Key associated with a specific Master Encryption Key.
2. Generation: Inside the Vault HSM, the MEK generates two distinct representations of the DEK: a Plaintext DEK and an Encrypted DEK (the DEK ciphertext wrapped by the MEK).
3. Local Encryption: Vault returns both keys to the Block Volume service. The Block Volume service uses the Plaintext DEK to encrypt the raw customer volume blocks at line rate using hardware-accelerated AES-256.
4. Erasure: Immediately following the encryption process, the storage service purges the Plaintext DEK from its volatile system memory.
5. Storage: The Encrypted DEK is written directly alongside the encrypted data payload as storage metadata. Because the DEK is encrypted, it cannot be used by an attacker even if the storage metadata is intercepted.
6. Decryption on Read: When an authorized compute instance requests to read the volume, the storage service sends the Encrypted DEK back to OCI Vault. The Vault HSM uses the MEK to decrypt the data key, securely transmits the Plaintext DEK back to the storage hypervisor in memory, and the data is transparently decrypted for authorized processing.

---

Key Management Models: Oracle-Managed vs. Customer-Managed Keys

When securing data across OCI storage and database services, organizations choose between two management models:

1. Oracle-Managed Keys (Default)

• Zero Administrative Overhead: By default, all data written to OCI storage services is encrypted using encryption keys generated, maintained, and rotated entirely by Oracle.
• Fully Automated: Oracle handles all aspects of key generation, storage, and lifecycle management. Customers do not need to create an OCI Vault, define IAM key policies, or manage key rotation schedules.
• Zero Cost: There is no additional charge for using Oracle-managed keys.
• Best Suited For: General-purpose cloud workloads, dev/test environments, and architectures where baseline encryption at rest is mandatory but regulatory mandates do not require customer-controlled key custody.

2. Customer-Managed Keys (CMK)

• Complete Customer Governance: The customer creates and controls their own Master Encryption Keys within an OCI Vault.
• Lifecycle & Rotation Control: Customers define their own cryptographic rotation policies (such as rotating keys automatically every 90 days or initiating on-demand rotations) and retain the ability to enable, disable, or schedule the permanent deletion of keys.
• Instant Cryptographic Erasure (Kill Switch):
  • If an organization disables a Customer-Managed Key in Vault, any OCI service (Block Volume, Object Storage, Database) using that key immediately loses the ability to decrypt data.
  • This provides an instantaneous, centralized security "kill switch" to neutralize compromised environments or satisfy urgent data containment protocols.
• Bring Your Own Key (BYOK):
  • Many regulated enterprises maintain existing investments in on-premises Hardware Security Modules (such as Thales, nCipher, or Entrust).
  • OCI Vault supports BYOK, enabling customers to generate RSA or AES keys inside their on-premises HSMs, wrap the key material using an OCI Vault wrapping key, and import it securely into OCI Vault.
  • This ensures cryptographic root-of-trust continuity across hybrid cloud environments and guarantees compliance with corporate sovereign key governance mandates.

---

OCI Secrets Management

In addition to managing cryptographic keys, OCI Vault provides a dedicated Secrets Management capability designed to solve the dangerous industry problem of credential sprawl.

The Problem of Hardcoded Credentials

In legacy development workflows, application developers frequently hardcode database connection strings, administrator passwords, third-party API tokens, SSH private keys, and TLS certificates directly into source code, Dockerfiles, or configuration scripts. If code is inadvertently pushed to a public repository or exposed via an application vulnerability, entire production environments become compromised.

How Secrets Management Operates

OCI Secrets Management eliminates hardcoded credentials by providing a secure, centralized, API-accessible vault for sensitive configuration data:

• Encrypted Storage: Secret contents are supplied base64-encoded, and the maximum allowable size for a secret bundle is 25 KB. Secrets are stored within OCI Vault and encrypted at rest using an assigned Vault Master Encryption Key.
• Fine-Grained IAM Access: Access to retrieve secrets is governed by strict OCI IAM policies. For example, an administrator can grant an application's Compute Dynamic Group permission to read a secret (ALLOW dynamic-group AppServers TO read secret-bundles IN COMPARTMENT Production), ensuring only authorized running instances can retrieve credentials at runtime.
• Secret Versioning: Secrets support automated version staging with distinct lifecycle states:
  • Current: The active secret version currently consumed by production workloads.
  • Pending: A newly staged secret version waiting to be validated during rotation.
  • Deprecated: A superseded secret version retained temporarily for rollback safety.
• Automated Secret Rotation: Integrated with OCI Functions, Secrets Management can trigger serverless functions to automatically rotate database user passwords on a scheduled cycle, updating the target database and the stored secret simultaneously with zero application downtime.

---

Comprehensive Data Encryption: At Rest and In Transit

Oracle Cloud Infrastructure enforces a strict defense-in-depth encryption posture across both data at rest and data in transit:

+-----------------------------------------------------------------------------------------+
|                     COMPREHENSIVE DATA ENCRYPTION IN OCI                                |
+-----------------------------------------------------------------------------------------+
| ENCRYPTION AT REST (Universal & Default)       | ENCRYPTION IN TRANSIT (Wire Protection)|
+------------------------------------------------+----------------------------------------+
| • Block Volume: AES-256 on boot & block disks  | • TLS 1.2+ for all Console & REST APIs |
| • Object Storage: AES-256 for all buckets      | • MACsec (IEEE 802.1AE) on FastConnect |
| • File Storage (FSS): AES-256 for files/meta   | • IPsec (AES-256) for Site-to-Site VPN |
| • Database TDE: AES-256 on Autonomous/Exadata  | • In-Transit Volume Encryption (Host-Storage) |
+------------------------------------------------+----------------------------------------+

1. Universal Encryption at Rest

In OCI, encryption at rest is mandatory, universal, and enabled by default across all storage tiers. Customers cannot turn off encryption at rest:

• Block Volume Service: All boot volumes and block volumes are automatically encrypted at rest using AES-256. Data is encrypted on the physical storage subsystem before being written to persistent solid-state drives.
• Object Storage Service: Every object uploaded to standard, infrequent access, or archive storage buckets is automatically encrypted with AES-256. Object checksums and metadata are similarly protected.
• File Storage Service (FSS): All enterprise shared file systems and snapshot metadata are encrypted at rest using AES-256.
• Database Services & Transparent Data Encryption (TDE): Enterprise database offerings—including Autonomous Database, Exadata Database Service, and Base Database Systems—automatically enforce Oracle Transparent Data Encryption (TDE). TDE encrypts all database table spaces, data files, redo logs, and undo logs using AES-256, protecting data against unauthorized operating system-level inspection.

2. Encryption in Transit (Data on the Wire)

Data moving across network boundaries is rigorously protected against eavesdropping and man-in-the-middle attacks:

• Console and API Endpoints: All interactions with the OCI Web Console, OCI Command Line Interface (CLI), Software Development Kits (SDKs), and REST APIs require TLS 1.2 or higher with modern cryptographic cipher suites.
• OCI FastConnect with MACsec: For dedicated private fiber connections bypassing the internet, OCI supports MACsec (Media Access Control Security, IEEE 802.1AE). MACsec delivers line-rate hardware-level Layer 2 point-to-point encryption (using AES-128 or AES-256 GCM) between customer edge routers and OCI FastConnect edge switches, ensuring data traversing physical telecom circuits is impenetrable.
• Site-to-Site VPN: Hybrid traffic traversing the public internet is encapsulated in redundant IPsec tunnels utilizing IKEv1/IKEv2 key exchange and AES-256 encryption.
• In-Transit Volume Encryption: OCI provides an optional in-transit encryption toggle for Block Volumes. When enabled, data traversing the internal datacenter network fabric between a compute instance hypervisor and the remote block storage system is encrypted on the fly.

---

Key Management & Cryptographic Options Comparison