Key Management Service:KMS security document

HSM-backed key management

Alibaba Cloud KMS connects to customer-managed HSM clusters through Encryption Service. When configured, all key management and cryptographic operations execute within the HSM security boundary. Hardware key material never leaves the HSM cluster. This architecture physically isolates cryptographic key material from the multi-tenant cloud infrastructure.

The HSM clusters deployed by Alibaba Cloud meet the FIPS 140-3 Level 3 certification standard from the National Institute of Standards and Technology (NIST). Certificate documentation is available upon request. The hosted cryptographic machines available through KMS are certified by either FIPS 140-3 Level 3 or the China State Cryptography Administration, supporting enterprise and industry-specific regulatory compliance requirements.

Private key physical isolation and protection

Private keys are stored exclusively within the tamper-resistant hardware of the HSM. Attackers cannot extract or copy private keys through export mechanisms, even in the event of an HSM compromise. Physical isolation serves as the primary security guarantee. HSM firmware integrity protection, measured boot processes, and firmware signing verification mechanisms are managed by Alibaba Cloud's infrastructure security team. Specific technical implementations — including firmware signature chains, secure boot measurement points, and anti-rollback protections — are documented in Alibaba Cloud's internal security compliance documentation and available for review under NDA.

HSM decommissioning and sanitization

Alibaba Cloud follows standardized hardware lifecycle management procedures for HSM decommissioning. Cryptographic key material is sanitized before the hardware is retired at end-of-life. Specific zeroization procedures, verification processes, and physical media destruction protocols are documented in Alibaba Cloud's infrastructure security operations runbooks. Decommissioning proof documentation is available to customers through the Alibaba Cloud compliance process upon request.

Tenant isolation architecture

Alibaba Cloud KMS 3.0 provides tenant isolation and dedicated instance architecture that exceeds the KMS 1.0 baseline:

• Dedicated KMS instances — Tenant-dedicated service instances deploy within your Virtual Private Cloud (VPC). This ensures private network access security compared to the shared KMS gateway model.

• Dedicated cryptographic resource pools — Tenant-dedicated cryptographic resource pools achieve resource and cryptographic isolation. This provides stronger security than shared resource and key computation models.

• Cross-tenant isolation — One tenant's operations cannot affect another tenant's keys, policies, or cryptographic operations. HSM partition boundaries are strictly enforced at the infrastructure level.

VPC endpoint

You can restrict all KMS API access for sensitive workloads to Alibaba Cloud VPC domain names (kms-vpc.<region>.aliyuncs.com). This ensures that KMS API traffic does not traverse the public internet. Key usage policies enforce source VPC and IP address allowlisting through conditional policy evaluation.

TLS communication security

KMS hardware key management instances communicate with HSM clusters through mutual TLS (mTLS) encrypted channels. All KMS API calls require TLS. The bidirectional authentication between the KMS service gateway and the HSM cluster prevents man-in-the-middle attacks and ensures the integrity and confidentiality of data in transit.

Key usage policy enforcement at API level

When an Alibaba Cloud account or RAM identity (RAM user or RAM role) initiates a KMS resource access request through the Alibaba Cloud console, OpenAPI, or CLI, the system evaluates permission policies to determine whether access is permitted. Key policies serve as the primary access control mechanism. RAM policies and resource-based authorization provide supplementary controls.

KMS supports resource types, actions, and conditional policy elements for fine-grained access control. Conditions include source IP address restrictions and request-time-based access controls.

Separation of duties and operator access controls

Alibaba Cloud KMS maintains documented separation of duties for internal key management operations. Personnel handling root keys and master keys are governed by strict access control matrices. The KMS service scope is covered by Alibaba Cloud's SOC 2 Type II and ISO 27001 certifications. Current third-party attestation reports covering the KMS infrastructure scope are available through the Alibaba Cloud compliance documentation portal.

Operator isolation from key policies

Alibaba Cloud KMS enforces separation between customer-managed key policies and internal operational access. Key policies are stored within the KMS control plane and subject to the same access controls as key material. RAM policies govern customer-side identity access to keys, and the KMS service enforces policy evaluation on every API call. Internal Alibaba Cloud operators do not have a direct path to modify customer key policies through operational interfaces. Policy modifications can only be initiated through the customer's authenticated API requests, console actions, or authorized automation workflows. Technical controls preventing internal operator bypass of customer key policies are documented in Alibaba Cloud's internal security architecture specifications.

Key access justification logging

KMS records all key usage events through ActionTrail. Each event captures the caller identity, timestamp, source IP address, requested action, and resource identifier. KMS does not natively require a business justification string with each API call, but enterprise customers can implement justification logging through integration with their identity governance platforms. You can correlate the ActionTrail log stream with internal change management systems to map each key access event to an approved change request or runbook entry, providing an audit-level justification trail.

Near-real-time access notification

You can stream KMS ActionTrail logs to Simple Log Service (SLS) for real-time processing and alerting. Configure SLS alert rules to trigger notifications when specific KMS API calls are detected, including operator identity, operation type, and timestamp. Route alerts to your controlled channels through SLS integrations such as webhooks, email, and message services. For enterprise customers, Alibaba Cloud support channels can provide additional notification workflows for operator-initiated access events. The near-real-time notification cadence depends on SLS alert configuration and is not a built-in SLA-backed feature of the KMS service.

Audit logging via ActionTrail and SLS

KMS integrates with Alibaba Cloud ActionTrail to provide comprehensive usage logging for all keys. ActionTrail records API call metadata, including the caller identity, timestamp, source IP address, requested action, and response elements. All sensitive KMS operations — including key deletion, disable, schedule-for-deletion, and policy modification — are logged for compliance auditing and operational monitoring.

You can direct all API call records from the instance service gateway to a designated OSS storage bucket for long-term retention and independent audit access. The SLS integration for KMS instances collects business request information processed by the KMS instance. Business request scenarios are identified through the api_name and share_gateway_api_name log fields for operational monitoring and compliance auditing.

Service binary and configuration control

Alibaba Cloud KMS follows strict change management procedures for production deployments. All changes to KMS service components undergo multi-party code review, independent approval, and signed or verified build processes. Deployment pipelines are subject to the same controls as the service binaries. Immutable audit logging records all deployment activities.

Emergency change procedures

Emergency-only changes proceed with expedited review, followed by retroactive review and documentation within a defined post-deployment window. Change notifications are communicated to enterprise customers through Alibaba Cloud's enterprise support channels.

Envelope encryption architecture

Alibaba Cloud KMS implements envelope encryption to protect customer data across all integrated services:

• Data Encryption Keys (DEKs) — Generated by KMS and used by individual cloud services to encrypt customer data at rest. Supported services include ECS, OSS, RDS, PolarDB, Redis, MongoDB, NAS, SLS, MQ, Model Studio, and others.

• Key Encryption Keys (KEKs) — Managed by KMS and used to encrypt (wrap) the DEKs. The KEK plaintext never leaves the KMS-managed HSM boundary for storage or use.

• DEK plaintext handling — DEK plaintext is used only in the memory of the host machine where your service instance runs. DEK plaintext is never persisted to any storage medium in any form.

This envelope encryption model ensures that data encryption keys for sensitive services are never available in unencrypted form on multi-tenant infrastructure. They are never persisted in non-volatile unprotected memory. The KEKs that wrap these DEKs, and all DEK wrap and unwrap operations, are confined to dedicated KMS infrastructure or HSM-backed infrastructure.

Key material storage security

Customer key material is encrypted and stored within the KMS HSM security boundary. Key material exists in plaintext form only within the HSM volatile memory during active cryptographic operations. When not in active use, key material is encrypted and stored in durable persistent storage. Plaintext key material never leaves the HSM security boundary.

No human operator interacts with plaintext cryptographic key material of any type within the KMS service. No mechanism exists for any individual, including Alibaba Cloud service operators, to view, access, or export plaintext key material.

Bring your own key (BYOK)

KMS supports Bring Your Own Key (BYOK). You can import your own key material into the managed cryptographic machines. Through BYOK, you maintain additional key copies offline while the managed cryptographic machines guarantee that imported keys cannot be exported.

The BYOK import process ensures end-to-end security:

• Customer-supplied key material is encrypted in transit to the HSM. TLS mutual authentication protects against man-in-the-middle attacks.

• The imported key material is decrypted within the HSM and re-encrypted under the HSM's internal symmetric key.

• Like all KMS key material, plaintext imported key material never leaves the HSM unencrypted.

Key rotation

KMS supports automatic and configurable key rotation policies. When key rotation is triggered:

• A new key version is created while preserving the original key ID, key ARN, and alias attributes.

• Previous key versions remain protected. They are retained exclusively for decryption of legacy ciphertext.

• Rotated key material is not exposed during or after the rotation process.

• Rotation schedules are configurable through KMS policies and can be enforced programmatically.

KMS does not delete any key version during rotation. Key versions are only removed when the parent key is explicitly deleted through the key deletion workflow.

Key deletion with waiting period

When you request key deletion:

• You must specify a pre-deletion waiting period. The configurable range is 7 to 366 days.

• The deletion process is fully audit-logged through ActionTrail.

• After the waiting period expires, the deletion is irreversible. All key versions are permanently destroyed.

• You can restore the key during the waiting period by canceling the scheduled deletion.

This workflow ensures that keys cannot be accidentally or maliciously removed without a recoverable window. After the waiting period, destruction is definitive and irreversible.

Internal root key lifecycle

Alibaba Cloud internal root keys follow equivalent lifecycle controls. These root keys are rotated on a defined cadence without exposing previous key material. Deletion of root keys requires multi-party authorization, is fully audit-logged, and becomes irreversible after a defined waiting window.

CMEK support across Alibaba Cloud services

Alibaba Cloud KMS supports customer-managed encryption keys (CMEK) across a broad range of services. The CMEK model allows you to maintain full control over your encryption keys while leveraging Alibaba Cloud services for data processing and storage. The following services integrate with KMS CMEK:

Storage services: OSS (Object Storage Service), NAS (File Storage), ECS Cloud Disks

Database services: RDS, PolarDB, Redis, MongoDB

Analytics and logging: SLS (Simple Log Service), DTS (Data Transmission Service)

Messaging and integration: MQ (Message Queue)

Network services: CDN

Security infrastructure: Bastionhost, ARMS, Secrets Manager, WAF, Cloud Firewall

AI/ML services: Model Studio

Key policies enforce CMEK usage requirements. Services cannot encrypt or decrypt data without explicit authorization from your key policy.

Supported algorithms

KMS supports industry-standard cryptographic algorithms for key management and cryptographic operations, including symmetric encryption, asymmetric encryption, digital signatures, and key derivation. KMS instances provide key management, data encryption and decryption, and digital signature computation through hardware-backed keys.

Algorithm policy enforcement

KMS supports policy-based algorithm selection. You can restrict which algorithms may be used with specific keys through key policies and RAM policies. This ensures that only approved cryptographic algorithms are used for sensitive workloads.

Audit trail for sensitive operations

All sensitive KMS operations are logged through ActionTrail. These include key deletion, disable, schedule-for-deletion, and policy modification. ActionTrail provides a complete record of all API calls for compliance auditing and operational monitoring. KMS instances support directing all API call records from the service gateway to a designated OSS storage bucket for long-term retention and independent audit access.

Multi-party authorization

For enterprise-grade deployments, Alibaba Cloud supports multi-party authorization workflows through RAM policies and Resource Directory governance. You can structure sensitive operations to require multiple approvers before execution. No single operator can independently perform critical key management actions. Integration with Alibaba Cloud's enterprise governance framework allows you to implement M-of-N approval patterns tailored to your operational requirements. Native integration of customer-side consent as a required approval step within the M-of-N workflow is not currently a built-in KMS capability. You would need custom integration through Alibaba Cloud's enterprise support channels.

KMS service availability

KMS is designed for high availability with distributed infrastructure across multiple availability zones within a region. The service maintains operational continuity during infrastructure failures through automatic failover. HSM cluster failover preserves tenant isolation guarantees without compromising key material security or access control policies.

During disaster recovery events, the KMS service preserves all customer-defined key policies and access controls. The failover mechanism does not bypass or override customer-configured policies. Specific emergency key restoration procedures that might require customer approval are documented in Alibaba Cloud's internal disaster recovery runbooks and are available for review under NDA.

Regional boundary enforcement

KMS keys are bound to their creation region by default. Cross-region key replication or failover requires explicit customer configuration. For sensitive workloads, you can maintain regional boundary enforcement through key policies that restrict key usage to designated regions. HSM cluster failover and cross-region backup mechanisms respect regional boundaries. They do not export key material to non-approved regions without customer consent.

Key backup and escrow

Alibaba Cloud KMS maintains key material durability through encrypted persistent storage within the HSM security boundary. Key material backup is handled through the HSM's internal durable storage mechanism. This mechanism is subject to the same operator-access restrictions and isolation controls as production key material. No escrow mechanism — Alibaba Cloud does not maintain a separate escrow copy of customer key material outside the HSM security boundary. Customer-managed backup — If you require additional key backup capabilities, use the BYOK feature to maintain offline key copies. Opt-out is default — Escrow opt-out is the default behavior, as KMS does not implement a key escrow mechanism.

Third-party certifications

Alibaba Cloud KMS infrastructure is covered by Alibaba Cloud's broader compliance certifications:

• SOC 2 Type II — Service Organization Control reporting covering security, availability, and confidentiality trust principles.

• ISO 27001 — Information Security Management System certification covering the KMS service scope.

• FIPS 140-3 Level 3 — HSM certification for cryptographic modules.

• China State Cryptography Administration Certification — Domestic cryptographic module certification for China region deployments.

Current attestation reports and certification documentation are available through the Alibaba Cloud Trust Center (alibabacloud.com/trust-center) and enterprise support channels.

Regulatory compliance support

KMS helps you meet regulatory compliance requirements across multiple jurisdictions. The service provides cryptographic foundations for data protection regulations, financial industry standards, and government security frameworks. KMS audit logging, key lifecycle controls, and access management support compliance evidence collection and auditor review.

Cryptographic attestation and transparent build verification

The following capabilities are under development or review. They are not yet available as standard KMS features:

• Cryptographically verifiable attestation documents — A service-published attestation document containing HSM or TEE identity, service binary measurements, and boot chain information. Customers can independently verify this document on a per-session basis.

• Attestation-bound key release conditions — Key release policies conditioned on caller-presented attestation matching customer-approved workload measurements. Currently, principal-based authentication through RAM and key policies serves as the primary access control mechanism.

• Transparent build log for production binaries — Publication of KMS production binary build attestations to an append-only transparency log with reproducible-build verification. Current change management processes include multi-party code review, signed builds, and immutable audit logging, but do not include an externally audible transparency log.