密码学里有一句老话:密钥泄露,一切皆空。再强的算法、再大的密钥,只要密钥管理出了问题,安全就归零。这一章来拆解密钥管理的完整生命周期。
一、密钥生命周期
1.1 密钥的六个阶段
| 阶段 | 安全要求 | 最佳实践 |
|---|---|---|
| 生成 | 安全随机数 | CSPRNG、KMS 生成 |
| 分发 | 加密传输 | TLS、信封加密 |
| 存储 | 加密存储 | HSM、KMS |
| 使用 | 最小暴露 | 内存中不持久化 |
| 轮换 | 定期更换 | 自动轮换、版本管理 |
| 销毁 | 彻底清除 | 加密擦除、HSM 销毁 |
1.2 密钥生命周期详解
每个阶段都有特定的安全威胁和对应的防护措施:
生成阶段的常见错误:
# 错误:使用不安全的随机数生成器import randomkey = random.randbytes(32) # 伪随机,可预测!# 错误:使用时间戳作为密钥种子import timekey = hashlib.sha256(str(time.time()).encode()).digest() # 可预测!
# 正确:使用密码学安全随机数生成器import oskey = os.urandom(32) # CSPRNG,不可预测
# 正确:使用 KMS 生成密钥(密钥不离开 KMS)import boto3kms = boto3.client('kms')response = kms.generate_data_key(KeyId='alias/my-key', KeySpec='AES_256')# 明文密钥只在内存中短暂存在,用后立即销毁分发阶段的关键原则:密钥永远不能明文传输。无论是从 KMS 到应用、还是从 CA 到服务节点,都必须通过加密通道(TLS 1.3)或信封加密传输。
使用阶段的内存安全:
# Python: 安全的密钥内存管理import ctypes
def secure_delete(buffer): """安全擦除内存中的密钥""" if isinstance(buffer, bytes): # 获取 buffer 的内存地址并覆写 ctypes.memset(id(buffer), 0, len(buffer)) del buffer
# 使用示例data_key = kms.generate_data_key(KeyId='alias/my-key', KeySpec='AES_256')['Plaintext']try: aesgcm = AESGCM(data_key) ciphertext = aesgcm.encrypt(nonce, plaintext, None)finally: secure_delete(data_key) # 确保密钥被擦除Python 的 del 语句并不保证内存被立即清零——垃圾回收时机不确定。在安全敏感场景中,应使用 ctypes.memset 或专门的密钥管理库(如 cryptography 的 ZeroPadding)。Go 语言中可以使用 memzero,Rust 中可以使用 zeroize crate。
二、KMS(密钥管理服务)
2.1 KMS 架构
| 功能 | 说明 |
|---|---|
| 密钥生成 | 在 HSM 中生成密钥,密钥不离开 HSM |
| 加密/解密 | 数据发送到 KMS,在 HSM 中加解密 |
| 信封加密 | KMS 加密数据密钥,本地用数据密钥加密数据 |
| 密钥轮换 | 自动轮换,旧版本仍可解密 |
| 访问控制 | IAM 策略控制谁可以使用密钥 |
| 审计 | 所有操作记录到 CloudTrail |
2.2 KMS 架构深入
KMS 的核心设计原则是密钥永不离开安全边界。无论是密钥生成、使用还是轮换,所有密码学运算都在 HSM 内部完成:
KMS 的请求处理流程:
- 应用通过 SDK 发送加密/解密请求
- API 网关进行认证(IAM 签名/OIDC Token)和限流
- 策略引擎检查调用者是否有权使用该密钥
- 密钥管理器查找密钥的当前版本
- HSM 池执行实际的密码学运算(加密/解密/签名)
- 返回结果,同时记录审计日志
2.3 AWS KMS 示例
# AWS KMS:信封加密import boto3
kms = boto3.client('kms')
# 生成数据密钥(信封加密)response = kms.generate_data_key( KeyId='alias/my-key', KeySpec='AES_256')plaintext_key = response['Plaintext'] # 明文数据密钥(用后即焚)encrypted_key = response['CiphertextBlob'] # 加密的数据密钥(存储)
# 用数据密钥加密数据from cryptography.hazmat.primitives.ciphers.aead import AESGCMaesgcm = AESGCM(plaintext_key)ciphertext = aesgcm.encrypt(nonce, plaintext, None)
# 存储加密数据 + 加密的数据密钥save_to_db(ciphertext, encrypted_key)
# 解密encrypted_key = load_from_db()response = kms.decrypt(CiphertextBlob=encrypted_key)plaintext_key = response['Plaintext']aesgcm = AESGCM(plaintext_key)plaintext = aesgcm.decrypt(nonce, ciphertext, None)2.4 三大云 KMS 对比
| 维度 | AWS KMS | Azure Key Vault | GCP KMS |
|---|---|---|---|
| 密钥类型 | 对称(AES-256)、非对称(RSA/ECC) | 对称、非对称、RSA、EC | 对称(AES-256)、非对称(RSA/EC) |
| HSM 支持 | FIPS 140-2 Level 2(默认)、Level 3(CloudHSM) | FIPS 140-2 Level 1(标准)、Level 2(托管) | FIPS 140-2 Level 3 |
| 自动轮换 | 每年自动 | 可配置 | 可配置 |
| 信封加密 | GenerateDataKey | Key Vault 加密 | 按需实现 |
| 审计 | CloudTrail | Azure Monitor | Cloud Audit Log |
| 密钥导入 | 自带密钥(BYOK) | BYOK | BYOK |
| 全球复制 | 多区域副本 | 多区域 | 多区域 |
| 免费额度 | 20000 请求/月 | 10000 操作/月 | 10000 操作/月 |
| 定价(每万次) | $0.03(加密/解密) | $0.03(加密/解密) | $0.03(加密/解密) |
三大云 KMS 的核心功能差异不大,选择主要看云平台绑定和合规需求。AWS KMS 与 CloudTrail 深度集成,审计最完善;Azure Key Vault 除了密钥管理还提供证书和秘密管理;GCP KMS 的 HSM 等级最高(Level 3)。
三、信封加密
3.1 为什么需要信封加密?
| 方案 | 问题 |
|---|---|
| 直接用 KMS 加密所有数据 | 数据量大,KMS 成为瓶颈 |
| 本地生成密钥加密 | 密钥管理困难 |
| 信封加密 | KMS 管理密钥密钥,本地加密数据 |
| 组件 | 说明 | 存储位置 |
|---|---|---|
| 主密钥(CMK) | KMS 中的根密钥 | KMS/HSM(永不导出) |
| 数据密钥(DEK) | 加密实际数据的密钥 | 加密后存储在应用 |
| 加密数据 | 业务数据 | 数据库/存储 |
3.2 信封加密流程详解
信封加密的核心思想是分层密钥管理:主密钥(CMK)保护数据密钥(DEK),数据密钥保护实际数据。这样做的优势是:
- 性能:大量数据不需要全部经过 KMS,只在本地用 DEK 加密
- 安全:CMK 永远不离开 KMS/HSM,DEK 只在内存中短暂存在
- 轮换:密钥轮换只需重新加密 DEK,不需要重新加密所有数据
3.3 信封加密代码实现
# 信封加密完整流程def encrypt_data(plaintext, kms_key_id): # 1. 从 KMS 获取数据密钥 response = kms.generate_data_key(KeyId=kms_key_id, KeySpec='AES_256') data_key = response['Plaintext'] # 明文密钥 encrypted_data_key = response['CiphertextBlob'] # 加密密钥
# 2. 用数据密钥加密数据 nonce = os.urandom(12) aesgcm = AESGCM(data_key) ciphertext = aesgcm.encrypt(nonce, plaintext, None)
# 3. 立即销毁明文密钥 del data_key
# 4. 返回加密数据 + 加密密钥 + nonce return { 'ciphertext': ciphertext, 'encrypted_data_key': encrypted_data_key, 'nonce': nonce }
def decrypt_data(encrypted): # 1. 用 KMS 解密数据密钥 response = kms.decrypt(CiphertextBlob=encrypted['encrypted_data_key']) data_key = response['Plaintext']
# 2. 用数据密钥解密数据 aesgcm = AESGCM(data_key) plaintext = aesgcm.decrypt(encrypted['nonce'], encrypted['ciphertext'], None)
# 3. 销毁明文密钥 del data_key
return plaintext3.4 信封加密的密钥层级
在大型系统中,信封加密通常不止两层,而是形成密钥层级(Key Hierarchy):
| 层级 | 密钥类型 | 生命周期 | 保护方式 | 轮换频率 |
|---|---|---|---|---|
| L0 | 根密钥(Root Key) | 永久(极少轮换) | HSM 硬件保护 | 3-5 年 |
| L1 | 密钥加密密钥(KEK) | 长期 | KMS + IAM 策略 | 1 年 |
| L2 | 数据加密密钥(DEK) | 短期 | 信封加密 | 每次加密或定期 |
| L3 | 派生密钥 | 一次性 | HKDF 派生 | 每次会话 |
信封加密的核心优势:1)数据密钥只在内存中短暂存在;2)主密钥永不离开 KMS/HSM;3)大量数据不需要全部经过 KMS,性能好;4)密钥轮换只需重新加密数据密钥,不需要重新加密所有数据。
四、HSM(硬件安全模块)
4.1 HSM 原理
HSM 是防篡改的硬件设备,专门用于密钥存储和密码学运算:
| 特性 | 说明 |
|---|---|
| 防篡改 | 物理攻击会触发密钥销毁 |
| 密钥不导出 | 密钥在 HSM 内生成,永不离开 |
| 高性能 | 专用密码学加速硬件 |
| 认证 | FIPS 140-2 Level 3 认证 |
| HSM 类型 | 说明 | 适用场景 |
|---|---|---|
| 本地 HSM | 物理设备 | 金融、政府 |
| Cloud HSM | 云服务 | AWS CloudHSM、Azure Dedicated HSM |
| 虚拟 HSM | 软件模拟 | 开发测试 |
4.2 FIPS 140-2 安全等级
FIPS 140-2 是美国国家标准与技术研究院(NIST)发布的密码模块安全标准,定义了四个递增的安全等级:
| 等级 | 物理安全 | 逻辑安全 | 典型应用 | 代表产品 |
|---|---|---|---|---|
| Level 1 | 无物理保护要求 | 基础软件加密 | 软件加密库 | OpenSSL(FIPS 模式) |
| Level 2 | 防篡改证据(封条) | 基于角色的认证 | 云 KMS 默认 | AWS KMS、Azure Key Vault |
| Level 3 | 防篡改响应(自动销毁) | 身份认证+密钥不导出 | 金融、PKI | AWS CloudHSM、Thales Luna |
| Level 4 | 全环境保护+主动防护 | 多层物理+逻辑防护 | 军事、最高安全 | 极少数厂商 |
Level 2 vs Level 3 的关键区别:
- Level 2:如果有人物理拆开 HSM,你事后能发现(封条被破坏),但密钥可能已经被读取
- Level 3:如果有人试图物理拆开 HSM,密钥会自动销毁(防篡改响应),攻击者无法获取密钥
# AWS CloudHSM:Level 3 HSM 操作示例from cloudhsmcli import HsmClient
# 连接到 CloudHSM 集群client = HsmClient( cluster_id='cluster-xxxxx', username='crypto_user', password=os.environ['HSM_PASSWORD'])
# 在 HSM 内生成 AES 密钥(密钥永不离开 HSM)key_handle = client.generate_aes_key( key_length=256, label='billing-dek', attributes=[ 'ENCRYPT', 'DECRYPT', # 允许加密/解密 'WRAP', 'UNWRAP', # 允许密钥包装 'EXTRACTABLE:FALSE', # 密钥不可导出 'SENSITIVE:TRUE', # 敏感密钥 ])
# 在 HSM 内执行加密(数据发送到 HSM,密钥不离开)ciphertext = client.encrypt( key_handle=key_handle, plaintext=b'sensitive data', mechanism='AES_GCM')
# 在 HSM 内执行解密plaintext = client.decrypt( key_handle=key_handle, ciphertext=ciphertext, mechanism='AES_GCM')4.3 KMS vs HSM
| 维度 | KMS | HSM |
|---|---|---|
| 部署 | 云服务 | 物理设备/云托管 |
| 密钥控制 | 云商管理 | 客户完全控制 |
| 成本 | 低(按使用计费) | 高(设备+运维) |
| 性能 | 中 | 高 |
| 合规 | 大多数场景 | 金融/政府严格合规 |
4.4 何时选择 HSM 而非 KMS?
| 场景 | 推荐 | 原因 |
|---|---|---|
| 一般 Web 应用 | KMS | 成本低,功能够用 |
| 多租户 SaaS | KMS | 按密钥隔离,IAM 策略灵活 |
| 金融支付系统 | HSM Level 3 | PCI DSS 合规要求 |
| 根 CA 私钥 | HSM Level 3 | 根密钥泄露=整个 PKI 崩溃 |
| 大批量加密(>10000 TPS) | HSM | 专用硬件性能更高 |
| 跨云密钥管理 | HSM(自建) | 不想被任何云商锁定 |
HSM 不是万能的。它保护密钥不被导出和窃取,但不能防止应用逻辑错误(比如用错误的密钥加密、或者把明文数据当密文存储)。安全是一个系统工程,HSM 只是其中一环。
五、密钥轮换
5.1 轮换策略
| 策略 | 说明 | 适用 |
|---|---|---|
| 定期轮换 | 每年/每季度 | 对称密钥 |
| 按需轮换 | 密钥泄露时 | 所有密钥 |
| 自动轮换 | KMS 自动管理 | AWS KMS |
| 版本管理 | 多版本共存 | 信封加密 |
5.2 轮换实现
# AWS KMS:自动密钥轮换kms.enable_key_rotation(KeyId='alias/my-key')
# 手动轮换:创建新密钥,更新别名kms.create_key(Description='New version of my-key')kms.update_alias(AliasName='alias/my-key', TargetKeyId=new_key_id)# 旧密钥仍可解密旧数据,新数据用新密钥加密5.3 密钥轮换策略详解
密钥轮换不是简单地”换一个新密钥”,而是一套系统性的策略,需要考虑向后兼容性、数据迁移和密钥版本管理。
策略一:别名轮换(Alias Rotation)
最简单的轮换方式——创建新密钥,将别名指向新密钥。旧密钥保留用于解密。
# 别名轮换流程def rotate_key_via_alias(key_alias): # 1. 创建新密钥 new_key = kms.create_key( Description=f'Rotated key for {key_alias}', Tags=[{'TagKey': 'RotatedFrom', 'TagValue': key_alias}] ) new_key_id = new_key['KeyMetadata']['KeyId']
# 2. 更新别名指向新密钥 kms.update_alias( AliasName=f'alias/{key_alias}', TargetKeyId=new_key_id )
# 3. 新数据自动使用新密钥(通过别名) # 4. 旧密钥保留,用于解密旧数据 print(f'Key rotated: {key_alias} -> {new_key_id}') print(f'Old key retained for decryption')策略二:信封加密轮换(Envelope Rotation)
信封加密的轮换更优雅——只需重新加密数据密钥(DEK),不需要重新加密所有业务数据:
# 信封加密密钥轮换def rotate_envelope_key(old_kek_id, new_kek_id, encrypted_dek): # 1. 用旧 KEK 解密 DEK response = kms.decrypt(CiphertextBlob=encrypted_dek) plaintext_dek = response['Plaintext']
# 2. 用新 KEK 重新加密 DEK new_encrypted_dek = kms.encrypt( KeyId=new_kek_id, Plaintext=plaintext_dek )['CiphertextBlob']
# 3. 销毁明文 DEK del plaintext_dek
# 4. 更新存储:替换加密的 DEK # 业务数据不需要重新加密! return new_encrypted_dek策略三:双写轮换(Dual-Write Rotation)
对于高可用性要求的系统,轮换期间同时用新旧密钥加密:
# 双写轮换class DualWriteKeyManager: def __init__(self, old_key_id, new_key_id): self.old_key_id = old_key_id self.new_key_id = new_key_id self.rotation_start = datetime.utcnow()
def encrypt(self, plaintext): """轮换期间:用新密钥加密,但保留旧密钥解密能力""" # 新数据只用新密钥加密 return envelope_encrypt(plaintext, self.new_key_id)
def decrypt(self, encrypted_data, encrypted_dek): """轮换期间:尝试新密钥解密,失败则用旧密钥""" try: return kms.decrypt(CiphertextBlob=encrypted_dek) except kms.exceptions.NotFoundException: return kms.decrypt(KeyId=self.old_key_id, CiphertextBlob=encrypted_dek)
def is_rotation_complete(self): """检查是否所有数据都已用新密钥重新加密""" return all_data_reencrypted(self.new_key_id)5.4 密钥轮换时间线
| 密钥类型 | 推荐轮换周期 | 原因 |
|---|---|---|
| 数据加密密钥(DEK) | 每次加密或每日 | 减少单密钥加密数据量 |
| 密钥加密密钥(KEK) | 每年 | 保护 DEK,轮换影响大 |
| 根密钥 | 3-5 年 | HSM 保护,轮换极复杂 |
| TLS 证书 | 90 天(Let’s Encrypt) | 减少证书泄露影响 |
| JWT 签名密钥 | 30-90 天 | 配合 JWKS 轮换 |
| API 密钥 | 90 天 | 减少泄露风险 |
密钥轮换时,旧密钥不能立即删除——仍有用旧密钥加密的数据需要解密。保留旧密钥直到所有用旧密钥加密的数据都已迁移或过期。
六、HashiCorp Vault
6.1 Vault 架构
HashiCorp Vault 是目前最流行的开源密钥管理平台,提供了 KMS + HSM + 密钥轮换 + 动态秘密的一体化方案:
6.2 Vault Transit 引擎:加密即服务
Vault 的 Transit 引擎提供了类似 KMS 的功能,但更灵活——支持多种算法、自动轮换、无需管理密钥:
# Vault Transit 引擎:加密即服务
# 1. 启用 Transit 引擎vault secrets enable transit
# 2. 创建加密密钥vault write -f transit/keys/my-app-key \ type=aes256-gcm96 \ exportable=false \ deletion_allowed=false
# 3. 加密数据vault write transit/encrypt/my-app-key \ plaintext=$(echo -n "sensitive data" | base64)# => Key Value# ciphertext vault:v1:ABCDEFG...
# 4. 解密数据vault write transit/decrypt/my-app-key \ ciphertext="vault:v1:ABCDEFG..."# => Key Value# plaintext c2Vuc2l0aXZlIGRhdGE=
# 5. 轮换密钥vault write -f transit/keys/my-app-key/rotate# 新数据用 v2 密钥加密,旧数据仍可用 v1 解密
# 6. 查看密钥版本vault read transit/keys/my-app-key# => keys map[1:map[...] 2:map[...]]# latest_version 2# min_version 1# Python: 使用 hvac 库操作 Vault Transitimport hvac
client = hvac.Client(url='https://vault.example.com', token=os.environ['VAULT_TOKEN'])
# 加密encrypt_response = client.secrets.transit.encrypt_data( name='my-app-key', plaintext=base64.b64encode(b'sensitive data').decode())ciphertext = encrypt_response['data']['ciphertext'] # vault:v1:...
# 解密decrypt_response = client.secrets.transit.decrypt_data( name='my-app-key', ciphertext=ciphertext)plaintext = base64.b64decode(decrypt_response['data']['plaintext'])
# 批量加密(高性能)batch_data = [ {'plaintext': base64.b64encode(f'record-{i}'.encode()).decode()} for i in range(1000)]batch_response = client.secrets.transit.encrypt_data( name='my-app-key', batch_input=batch_data)6.3 Vault 动态秘密
Vault 的动态秘密功能可以为数据库、云服务等自动生成短期凭据,用完自动回收——这是最小权限原则的极致实践:
# Vault 动态数据库凭据# 配置 PostgreSQL 连接resource "vault_database_secret_backend_connection" "postgres" { backend = "database" name = "billing-postgres" allowed_roles = ["billing-readonly", "billing-readwrite"]
postgresql { connection_url = "postgresql://{{username}}:{{password}}@postgres:5432/billing" username = "vault_admin" password = var.db_password }}
# 定义只读角色resource "vault_database_secret_backend_role" "readonly" { backend = vault_database_secret_backend_connection.postgres.backend name = "billing-readonly" db_name = vault_database_secret_backend_connection.postgres.name
default_ttl = "1h" # 凭据有效期 1 小时 max_ttl = "4h" # 最大续期 4 小时
creation_statements = [ "CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';", "GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" ] revocation_statements = [ "DROP ROLE IF EXISTS \"{{name}}\";" ]}6.4 Vault vs 云 KMS
| 维度 | HashiCorp Vault | AWS KMS | Azure Key Vault |
|---|---|---|---|
| 部署 | 自托管/托管(HCP) | 云服务 | 云服务 |
| 多云支持 | 云无关 | AWS only | Azure only |
| 动态秘密 | 数据库/云凭据 | ||
| Transit 加密 | 加密即服务 | 信封加密 | 信封加密 |
| PKI 管理 | 内置 CA | 需要 ACM | 证书管理 |
| 密钥轮换 | 自动+版本管理 | 自动 | 自动 |
| 成本 | 自托管免费/托管付费 | 按使用付费 | 按使用付费 |
| 运维复杂度 | 高 | 低 | 低 |
如果你是多云环境或需要动态秘密,Vault 是更好的选择。如果你完全在单一云上且不需要动态秘密,云 KMS 更简单。很多团队采用混合方案:Vault 管理应用秘密和动态凭据,云 KMS 管理根密钥和信封加密。
七、密钥管理最佳实践
7.1 密钥管理检查清单
密钥生成
- 使用 CSPRNG 或 KMS 生成密钥,不要自行实现随机数生成
- 密钥长度符合 NIST 推荐:AES-256、RSA-3072+、ECDSA-P256+
- 密钥在 HSM 或 KMS 内生成,永不导出
密钥存储
- 主密钥存储在 HSM/KMS,不存储在配置文件或环境变量中
- 数据密钥加密后存储,明文只在内存中短暂存在
- 密钥元数据(ID、版本、创建时间)与密钥分离存储
密钥使用
- 每个应用/环境使用独立的密钥(隔离原则)
- 密钥使用后立即从内存中清除
- 限制密钥的使用场景(加密-only、签名-only)
密钥轮换
- 启用自动轮换(KMS 默认每年轮换)
- 旧密钥保留用于解密,设置过期时间
- 轮换后验证新密钥工作正常
密钥销毁
- 使用加密擦除(删除加密 DEK 的 KEK)
- 物理销毁 HSM 中的密钥
- 记录销毁操作到审计日志
7.2 密钥泄露应急响应
# 密钥泄露应急响应流程class KeyLeakResponse: """密钥泄露应急响应"""
def step1_contain(self, leaked_key_id): """1. 遏制:立即禁用泄露密钥""" kms.disable_key(KeyId=leaked_key_id) # 撤销所有使用该密钥的 IAM 策略 revoke_key_policies(leaked_key_id)
def step2_assess(self, leaked_key_id): """2. 评估:确定泄露范围""" # 查询审计日志:该密钥被谁使用过 usage_log = query_cloudtrail(key_id=leaked_key_id) # 确定哪些数据用该密钥加密 affected_data = find_encrypted_data(key_id=leaked_key_id) return usage_log, affected_data
def step3_rotate(self, leaked_key_id): """3. 轮换:创建新密钥""" new_key_id = kms.create_key( Description=f'Replacement for leaked key {leaked_key_id}' )['KeyMetadata']['KeyId'] kms.update_alias( AliasName=get_alias_for_key(leaked_key_id), TargetKeyId=new_key_id ) return new_key_id
def step4_reencrypt(self, new_key_id, affected_data): """4. 重加密:用新密钥重新加密所有受影响数据""" for data_record in affected_data: # 解密旧数据 plaintext = decrypt_with_key(data_record, leaked_key_id) # 用新密钥重新加密 reencrypt_data(data_record, plaintext, new_key_id)
def step5_audit(self, leaked_key_id): """5. 审计:记录事件并改进流程""" incident_report = { 'leaked_key_id': leaked_key_id, 'detection_time': datetime.utcnow(), 'containment_time': ..., 'affected_data_count': ..., 'root_cause': investigate_leak_cause(), 'prevention_measures': suggest_improvements() } save_incident_report(incident_report)密钥泄露是最严重的安全事件之一。响应速度每秒都意味着更多数据暴露——从发现泄露到禁用密钥的时间越短,损失越小。建议定期演练密钥泄露应急响应流程,确保团队熟悉操作步骤。
八、总结
上一章从全景视角介绍了零信任架构。
| 维度 | 关键要点 |
|---|---|
| 生命周期 | 生成→分发→存储→使用→轮换→销毁,每阶段都有特定威胁 |
| KMS | 云密钥管理,信封加密,自动轮换,三大云功能相近 |
| HSM | 硬件安全模块,密钥不导出,FIPS 140-2 Level 3 认证 |
| 信封加密 | KMS 管理密钥密钥,本地加密数据,密钥层级分层管理 |
| 轮换 | 别名轮换、信封轮换、双写轮换,旧密钥保留用于解密 |
| Vault | 开源密钥管理,Transit 加密即服务,动态秘密,多云支持 |
| 应急 | 密钥泄露五步响应:遏制→评估→轮换→重加密→审计 |
支持与分享
如果这篇文章对你有帮助,欢迎支持作者或分享给更多人
部分信息可能已经过时






