Oracle TDE 大小钥匙 HSM DEK 与 EDB key.bin

jnrjian2026-10-22 11:05

ADMINISTER KEY MANAGEMENT SET KEYSTORE 和 set key

在 Oracle 数据库中（从 12c 开始引入的透明数据加密 TDE 统一管理命令），ADMINISTER KEY MANAGEMENT 用于管理软件/硬件密钥库（Keystore）和主加密密钥。 [1](https://www.google.com/goto?url=CAESmgEB6zswFRoYPs76D_oPPGp7O5z478vN741iF0jiUbvjTM9YIXX3w_1FtE8AfDYC_dgN1V6gOw98-PPwf8dXr71ppFxnAT_4tlp24yoQIV1UVJ72ySfbknZEFJUrY70wr6unVhV_knE3tQtsHSMyauec7oVt5rSXBVwnAh5KDvBv39LLhUuaSKNxKdGuEXo7IbhjFlJKEYggxV_e "1"), [2](https://www.google.com/goto?url=CAEScwHrOzAVD563zzIE7-2bK2JhmEICKC1GPVmvNjCeY_MuwDWPEhjU_upZXsJm54ZOdjP8xyivcRUe10VsIqdQnGv4ezZPceoRmmfRzRbPsCOcm0tIkj5J8v2fMLHRgV1w_u0yqIpuqsqj6SclLDkLdtGEdv0 "2")

关于 SET KEYSTORE 与 SET KEY 的核心区别和用法如下：

  1. ADMINISTER KEY MANAGEMENT SET KEYSTORE
  • 作用 ：用于更改密钥库（Keystore / 钱包）本身的运行状态 ，例如打开（OPEN）或关闭（CLOSE）密钥库。 [1](https://www.google.com/goto?url=CAESmgEB6zswFRoYPs76D_oPPGp7O5z478vN741iF0jiUbvjTM9YIXX3w_1FtE8AfDYC_dgN1V6gOw98-PPwf8dXr71ppFxnAT_4tlp24yoQIV1UVJ72ySfbknZEFJUrY70wr6unVhV_knE3tQtsHSMyauec7oVt5rSXBVwnAh5KDvBv39LLhUuaSKNxKdGuEXo7IbhjFlJKEYggxV_e "1")
  • 常见语法示例 ：

    • 打开密钥库 （必须在设置主密钥前打开）：

      sql

      复制代码 
      ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "<keystore_password>";

      请谨慎使用此类代码。

    • 关闭密钥库 ：

      sql

      复制代码 
      ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "<keystore_password>";

      请谨慎使用此类代码。

  1. ADMINISTER KEY MANAGEMENT SET KEY
  • 作用 ：用于设置或轮换（Rotate）TDE 的主加密密钥（Master Encryption Key） 。在执行该命令前，密钥库必须已经处于 OPEN 状态。 [1](https://www.google.com/goto?url=CAESmgEB6zswFaX_XgcBKx1osiOR9x26CmW4aA0oANe7a32E7ath3qSmfnDwTXtouTPrJpf97lFe1EpNlU34oh9QDwjhehgOPvzu8xwYBVpYWGXo4-2xOjmRxFvuJBXpzJxMooyT4l_co2YVHH4MkGnXWDjFC6etUXHfo_gf7aWVW3fIOu0UYkkGdbgE_H9Iy6NVqdrgJv1JtW_mKjs4 "1")
  • 常见语法示例 ：

    • 设置/生成新的主密钥 （密码保护的软件密钥库通常要求带上 WITH BACKUP 备份子句）： [1](https://www.google.com/goto?url=CAESvwEB6zswFfY6-4G6z-1rjQkVkWN1ni6LKU62zt7L1Ck5oMwvCce8MeN9LAYa9-g18bAtNt4BIw4Ie72znwoE-Yn1U2tY4B9Bc09v-qyg38Bjf5eIzDkic5B31pcS5L2K1Yg7n22xQufuzPR59CHW4FuBflosmTJOcEd5UQk3_Cnyo5yeisBeIeBPSvjXSe3tiDGWkxlypod1ck093mINlcWUYNKbFxWttYBdEI_LQhzugjFJgLqac-oy0yqdEaosjg "1"), [2](https://www.google.com/goto?url=CAESmgEB6zswFRoYPs76D_oPPGp7O5z478vN741iF0jiUbvjTM9YIXX3w_1FtE8AfDYC_dgN1V6gOw98-PPwf8dXr71ppFxnAT_4tlp24yoQIV1UVJ72ySfbknZEFJUrY70wr6unVhV_knE3tQtsHSMyauec7oVt5rSXBVwnAh5KDvBv39LLhUuaSKNxKdGuEXo7IbhjFlJKEYggxV_e "2")

      sql

      复制代码 
      ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "<keystore_password>" WITH BACKUP;

      请谨慎使用此类代码。

总结对比

命令 操作对象 典型动作 前置条件
SET KEYSTORE 密钥库状态本身 打开 (OPEN ) 或关闭 (CLOSE ) 密钥库 密钥库已创建且路径参数（如 WALLET_ROOT ）配置完毕
SET KEY TDE 主加密密钥 生成并激活新的主加密密钥 密钥库必须已处于 OPEN 状态

KEYSTORE 是钱包入口？

是的，可以这样理解。

在 Oracle 数据库的专业术语中，KEYSTORE （密钥库）就是"钱包"（Wallet）在命令和架构层面的代名词 1, 2。从 Oracle 12c 开始，Oracle 统一将以前的术语"Wallet"改称为"Keystore"，但它们本质上是同一个东西。

如果把 TDE（透明数据加密）比作保护数据库的一道大门，它们的逻辑关系如下：

  1. 密钥库（Keystore / 钱包） = 保险箱
  • 它在操作系统中表现为一个具体的文件（例如 ewallet.p12 ）2, 3。
  • 它就像一个物理保险箱 ，用来安全地存放真正用来加密数据库的那些"钥匙"（主加密密钥 Master Key）3。
  • 执行 SET KEYSTORE OPEN ，就等于拿密码把这个保险箱的门打开。
  1. 主密钥（Master Key） = 保险箱里的钥匙
  • 只有打开了保险箱（SET KEYSTORE OPEN ），数据库引擎才能拿到里面的钥匙（Master Key ）。
  • 拿到钥匙后，数据库才能去解密和读取那些被加密的数据文件或表空间。

为什么说它是"入口"？

因为所有的密钥操作都必须以它为起点。

  1. 数据库启动后，默认这个"入口"是关闭的，数据库拿不到钥匙，无法读取加密数据。
  2. 你必须先通过 SET KEYSTORE OPEN 激活这个入口。
  3. 入口打开后，你才能进到里面去创建、修改或者轮换具体的密钥（SET KEY ）1。

请问你目前在操作时，是遇到了钱包无法打开 的问题，还是想了解如何配置**自动打开（Auto-login）**钱包而无需每次输入密码？

轮换后的密钥可以打开之前的文件吗

可以，完全可以。 轮换主密钥不会 导致以前加密的文件或数据无法打开，这也是 Oracle TDE（透明数据加密）设计的核心机制。 其背后的工作原理称为双层密钥架构（Two-Tier Key Architecture）：

  1. 为什么能打开？（核心原理）

在 Oracle 中，数据的加密和解密实际上使用的是表空间密钥（Data Encryption Key，简称 DEK），而不是你轮换的那个主密钥（Master Key）。

  • 底层（DEK） ：每个加密的表空间都有自己独立的 DEK，这个 DEK 是永远不会变的。它直接用来加密和解密你的数据文件。
  • 顶层（Master Key） ：你通过 SET KEY 轮换的"主密钥"，它的唯一作用是把底层那个变的数据密钥（DEK）加密后包裹起来。
  1. 轮换（Rotate）时到底发生了什么？

当你执行 ADMINISTER KEY MANAGEMENT SET KEY... 轮换主密钥时：

  1. 数据库生成一个全新的主密钥（Master Key v2）。
  2. 数据库用旧的主密钥（Master Key v1）解密出数据密钥（DEK）。
  3. 数据库用全新的主密钥（Master Key v2）重新加密 DEK ，并存回密钥库。（数据文件头？？）
  4. 底层的历史数据文件完全没有被重写或修改，它们依然使用那个没变过的 DEK。

因此，轮换后，数据库只需要用新的主密钥解密出 DEK，就能顺理成章地读取以前所有的历史加密文件。

⚠️ 唯一需要注意的风险：备份

虽然新密钥可以解密旧文件，但**旧的备份文件（比如轮换前备份的临时钱包文件或全备）**可能仍然需要旧的主密钥。

  • 最佳实践 ：每次执行 SET KEY 轮换密钥时，Oracle 都会强烈建议（或强制要求）使用 WITH BACKUP 子句。请务必妥善保管好密钥库（Wallet）文件的历史副本，绝对不能删除任何历史密钥记录。

你目前是准备在生产环境 进行密钥轮换，还是在做**灾备（Data Guard）或数据恢复（RMAN）**的规划？如果涉及异地恢复，密钥的同步非常关键，需要我为你补充相关的注意事项吗？

WITH BACKUP 子句

在执行 ADMINISTER KEY MANAGEMENT SET KEY 轮换主密钥时，WITH BACKUP 子句的作用是：在修改密钥库（Keystore）之前，强制要求数据库自动对当前的钱包文件进行备份。

对于基于密码保护的软件密钥库（Password-based Software Keystore），Oracle 通常会强制要求加上这个子句，否则命令会直接报错。

  1. 为什么必须有 WITH BACKUP ？

密钥轮换（Rotate）是一个高风险操作。如果在新密钥写入钱包文件的瞬间发生断电、磁盘故障或文件损坏，而你又没有旧钱包的备份，那么整个数据库中所有加密的数据将永远无法恢复（因为旧密钥丢失，DEK 无法被解密）。

因此，Oracle 引入该子句作为一种强保护机制。

  1. 它的工作原理

当你执行以下命令时：

sql

复制代码 
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "你的密码" WITH BACKUP;

请谨慎使用此类代码。

Oracle 会在后台自动完成以下步骤：

  1. 自动复制 ：在操作生效前，它会克隆当前的钱包文件（如 ewallet.p12 ）。

  2. 重命名备份：备份文件的命名规则通常会带上时间戳（标识它是哪一天、哪一秒备份的），或者使用默认的旧命名标识。

  3. 写入新密钥：确认备份文件安全落盘后，Oracle 才会把新生成的主密钥写入原钱包文件中。

  4. 可选参数：自定义备份标识 USING

除了让 Oracle 自动命名，你还可以使用 USING 关键字为备份文件指定一个自定义的后缀或标识，方便日后识别：

sql

复制代码 
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "你的密码" 
WITH BACKUP USING 'before_rotate_20261021';

请谨慎使用此类代码。

执行后，在钱包目录下（WALLET_ROOT 对应路径）就会生成一个包含 before_rotate_20261021 字样的备份钱包文件。

💡 生产运维避坑指南

  1. 不要误删这些备份文件：有些管理员在轮换成功后，觉得旧的备份钱包没用了就随手删掉。请千万不要这样做！如果以后需要恢复很久以前的 RMAN 备份或冷备份，可能仍需要这些历史备份钱包中的旧密钥。
  2. 硬件加密（HSM）通常不需要 ：如果你使用的是硬件安全模块（HSM / Hardware Keystore），密钥存在硬件芯片中，通常不需要也不支持 WITH BACKUP 子句，因为硬件自身有同步和备份机制。

你目前在测试环境执行带 WITH BACKUP 的命令时是否遇到了报错 ？或者想知道如何查看当前钱包目录下已经生成了哪些备份文件？

在轮换主密钥（Master Key）后，之前加密的历史数据依然可以正常解密和读取 。 [1](https://www.google.com/goto?url=CAEScwHrOzAVSpeFIuiitPdRp4C_GhK21SWYC1DgUjSDZMCZBCG7aRSm0ioBKXjcf-3F9v0p-C-oNKMtK2-dPhNj8UUOw3_kEcWnuU3DNGtLX6k5L5FO_1d1XPQOTIIuFQ43hYv8C_s8ZpcHx4-rkfTcGaMH0D0 "1"), [2](https://www.google.com/goto?url=CAEScwHrOzAVsKJvQsnUN8rwZjBxrIn4UE3k5c5Ji7eASranxYQdfBHkKxw_2X3OptU9AHTWRMRlviTxVVxV59vEI-xG8Zv2AvTQpEmO1jDmA4ybqxDdxlqVIYhcX2poz_u4VMbaGvJaVuH8W63Ro8Mv95x-kD0 "2")

核心工作原理

  • 保留历史密钥：执行密钥轮换时，旧的密钥并不会被删除，而是被移入归档或停用状态，并保存在密钥库（Keystore / Wallet）中。
  • 自动版本匹配：历史数据或表空间的头部会记录当时加密所使用的密钥版本标识（Tag/ID）。当数据库读取这些数据时，会自动匹配并调用对应版本的旧密钥来进行解密。
  • 不强制重加密 ：轮换主密钥本身只是生成了新密钥，不会 自动把历史数据用新密钥重新加密一遍（除非你对表或表空间执行特定的 REKEY 操作）

密钥存在硬件芯片中 这是什么密钥

密钥存在硬件芯片中，这种密钥通常被称为"硬件密钥"，而保存并管理它的硬件设备叫做 HSM（Hardware Security Module，硬件安全模块）。 1

在企业级安全架构中，这是最高级别的密钥保护方式。与我们前面提到的"软件钱包"（把密钥存放在操作系统的文件里，如 ewallet.p12 ）不同，硬件芯片中的密钥具有**"只进不出"**的特性。

  1. 它是如何工作的？

如果说软件钱包是一个"保险箱文件"，那么硬件芯片（HSM）就是一个由特制芯片组成的物理防弹保险柜 1。

  • 密钥在芯片内生成：主加密密钥（Master Key）直接在 HSM 芯片内部利用物理真随机数发生器生成。
  • 密钥永不离开芯片：任何人都无法通过命令、代码或物理手段把这个主密钥从芯片里"复制"或"下载"出来。
  • 解密在芯片内完成 ：当 Oracle 数据库需要解密表空间密钥（DEK）时，数据库把加密的 DEK 发送给 HSM 芯片，芯片在自己内部完成解密，然后把结果返回给数据库。数据库服务器的内存和硬盘上从始至终都不会出现主密钥的明文。
  1. 硬件芯片长什么样？

在实际的机房和服务器中，这种硬件通常表现为：

  1. PCIe 加密卡：直接插在数据库服务器主板上的特制卡（类似于显卡，但专门用于加密和存储密钥）。

  2. 网络 HSM 机架服务器：一台独立的、有严密物理防拆设计的网络设备（例如 Thales Luna HSM、Fortanix 或 AWS CloudHSM），全公司的数据库和应用都通过网络连接它来请求密钥服务。

  3. 在 Oracle 中的命令变化

因为密钥由硬件接管，Oracle 的管理命令会发生变化：

  • 不需要 WITH BACKUP ：因为硬件芯片有自己的集群同步或专门的硬件备份卡，Oracle 无法也无需去备份硬件芯片内部的数据。
  • 语法指定为 LOCATION HARDWARE ：在配置时，需要告诉 Oracle 密钥库的类型是硬件（早期版本通过配置 sqlnet.ora ，新版本直接在统一密钥管理中识别）。

📊 软件钱包 vs 硬件芯片 (HSM) 快速对比

特性 软件钱包 (Software Keystore) 硬件芯片 (HSM / Hardware Keystore)
存储介质 服务器硬盘上的 .p12 文件 独立的物理硬件防拆芯片
安全性 较低（如果黑客拿到 root 权限，可能窃取钱包文件） 极高（符合 FIPS 140-2 安全标准，暴力拆解芯片会自动销毁密钥）
密钥备份 依赖执行命令时的 WITH BACKUP 产生新文件 依赖硬件厂商自带的设备间同步或硬件备份密钥 1
适用场景 测试环境、中小型企业、云端标准配置 金融、银行、政府、核心生产系统等强合规场景

你们公司目前是已经采购了硬件加密机（HSM）准备与 Oracle 数据库进行对接，还是在进行技术选型和合规性评估？如果需要，我可以为你提供 Oracle 联接 HSM 的通用配置思路。

解密在芯片内完成：当 Oracle 数据库需要解密表空间密钥（DEK）时，数据库把加密的 DEK 发送给 HSM 芯片，芯片在自己内部完成解密，然后把结果返回给数据库。数据库服务器的内存和硬盘上从始至终都不会出现主密钥的明文。 详细说说

-----解密后的DEK在内存中的，数据库不重启就不会消失，不需要多次加解密

你提到的这个过程，正是**硬件安全模块（HSM）**能够实现"绝对安全"的核心机密。我们可以把这个过程拆解得更详细一些，看看 Oracle 数据库和 HSM 芯片之间是如何进行这场"不见面"的密码传递的。

整个过程可以分为 "初始化（加密）" 和 "日常读取（解密）" 两个阶段：

第一阶段：初始化（表空间创建时）

当你在 Oracle 中创建一个加密表空间时，数据库和 HSM 芯片会完成以下互动：

  1. 数据库生成 DEK ：Oracle 数据库在自己的内存中生成一个用于加密数据的表空间密钥（DEK）。
  2. 请求硬件加密 ：Oracle 内存中的 DEK 此时是明文，为了把它安全地存盘，Oracle 通过专用的安全接口（通常是 PKCS#11 协议）把这个 DEK 发送给 HSM 芯片，并对芯片说："请用你的主密钥帮我把它加密。" 不是安全， 是加密存
  3. 芯片内加密 ：DEK 进入 HSM 芯片。芯片调用深藏在硬件内部、永不外泄的主密钥（Master Key） ，对 DEK 进行加密，生成一个被包裹住的加密 DEK（Wrapped DEK）。
  4. 存入数据库 ：HSM 芯片把这个 Wrapped DEK 返回给 Oracle 数据库。Oracle 把这个加密后的密文存放在数据字典或数据文件头部（.dbf ）。此时，即使黑客把硬盘偷走，也只能看到被加密的 DEK，没有 HSM 芯片它就无法解密。

第二阶段：日常读取（数据库启动或首次读取数据时）

当数据库重启，或者用户第一次去读取这个加密表空间的数据时，最关键的**"芯片内解密"**发生了：

复制代码 
[ Oracle 数据库 (内存) ]                                [ HSM 硬件芯片 (内部) ]

         |                                                       |
         | ---- 1. 发送加密的 DEK (Wrapped DEK) -----------------> |
         |                                                       | -- 2. 找到主密钥 (Master Key)
         |                                                       | -- 3. 在芯片内部解密出明文 DEK
         |                                                       |
         | <--- 4. 返回明文 DEK (通过受保护的安全通道) ----------- |
         |                                                       |
[ 留在 Oracle 内存中 ]
  1. Oracle 发起请求 ：Oracle 从数据文件头部读取出 Wrapped DEK（加密的 DEK）。因为没有明文 DEK 数据库就无法解密磁盘上的用户数据，所以 Oracle 把这个 Wrapped DEK 发送给 HSM 芯片。
  2. 硬件内部解密：Wrapped DEK 进入了 HSM 芯片。芯片在完全隔离的硬件安全边界（Cryptographic Boundary）内部，使用它的 Master Key 对其进行解密，还原出明文的 DEK。
  3. 返回解密结果 ：HSM 芯片通过与数据库服务器之间建立的受保护的安全传输通道 ，将解密后的明文 DEK 返回给 Oracle 数据库的内存。
  4. 数据库解密数据：Oracle 数据库拿到明文 DEK 后，暂存在自己的安全内存区域（SGA 的 Encrypted Key Cache 中），用来实时解密从磁盘读入 Buffer Cache 的用户数据（比如用户的姓名、银行卡号）。

为什么说"主密钥明文从始至终不会出现"？

通过上面的流程，你会发现两种密钥的宿命完全不同：

  • 表空间密钥（DEK） ：在 Oracle 的内存 中会以明文存在（因为数据库引擎需要高频地用它来解密具体的数据块，如果每次读一个数据块都要走网络去问硬件，数据库性能会彻底崩溃）。但它在硬盘上永远是密文。
  • 主密钥（Master Key） ：无论是硬盘还是内存，它在数据库服务器上从未出现过。 它的明文只存在于 HSM 那颗特制的、有物理防拆涂层的芯片晶圆内部。

硬件芯片的"物理防拆"有多变态？

为了保证主密钥绝对不出芯片，这些硬件（符合 FIPS 140-2 Level 3 或 Level 4 标准）具有物理自毁机制：

  • 电压/温度监控 ：如果黑客企图用微针探测芯片、或者通过极端高低温、异常电压干扰芯片来读取信号，芯片会瞬间触发自毁，抹除主密钥。
  • 物理防拆网 ：芯片外层包裹着极细的导电网格，一旦外壳被剥开或钻孔导致网格断开，芯片立刻在几毫秒内清除密钥。

因此，这种"解密在芯片内完成"的架构，把最核心的"信任根（Root of Trust）"从软件层抽离，死死地锁在了物理硬件里。

了解了硬件解密的底层逻辑后，如果你们正在规划部署，你是否需要了解 Oracle 数据库如何通过 PKCS#11 驱动与 HSM 硬件建立连接 ？或者想探讨一下高并发下，硬件解密对数据库性能的具体影响？

• 数据库服务器的内存和硬盘上从始至终都不会出现主密钥的明文。 明文在哪

主密钥的明文，从始至终只存在于硬件芯片（HSM）内部的"绝对安全区"内，也就是那颗物理芯片的硅晶圆（内部寄存器/内存）里。

为了让你彻底明白它在哪里、以及为什么黑客拿不到，我们可以把范围缩小到这颗硬件芯片的微观结构内部来看：

  1. 它的物理位置：HSM 芯片内的 Volatile Key Register（易失性密钥寄存器）

硬件加密机（HSM）的内部有一颗专门定制的、高度安全的 CPU/微控制器。在这颗芯片内部，有一块极小的、与外界完全物理隔离的存储区域。

  • 当系统通电并激活硬件时，主密钥的明文就会被加载到这个芯片内部的寄存器或内部 SRAM 中。
  • 它绝不走出这颗硅片： 芯片的电路设计在硬件层面上封死了读取这条总线的可能。芯片没有提供任何一条"将主密钥明文传出引脚"的指令。
  1. 软件钱包 vs 硬件芯片的明文对比（看清区别）

为了对比，我们来看看"明文"在两种模式下的位置：

🔓 模式 A：软件钱包（没有硬件，只用文件）

  1. 硬盘上 ：主密钥以密文形式存在于 ewallet.p12 文件中。
  2. 内存中 ：当你执行 SET KEYSTORE OPEN 输入密码后，Oracle 会在数据库服务器的操作系统内存（RAM） 中解密出主密钥的明文。
    • 风险 ：如果黑客拿到操作系统的 root 权限，使用内存dump工具（如 gdb 或恶意软件），是有可能从操作系统的内存中直接偷走主密钥明文的。

🔒 模式 B：硬件芯片（HSM 模式）

  1. 硬盘上 ：数据库服务器的硬盘上完全没有主密钥。
  2. 服务器内存中 ：数据库服务器的内存（RAM）里完全没有主密钥。
  3. 明文到底在哪？ ：它只在物理上位于机房另一端的 HSM 硬件机箱里、那颗被特殊金属和树脂包裹的芯片内部的硅晶圆上。
  1. 如果黑客用物理手段"切开"芯片呢？

你可能会问："既然明文在芯片的硅晶圆里，如果黑客把芯片偷走，用电子显微镜或者物理微针去刺探芯片内部，不就能读到明文了吗？"

这就是硬件芯片（符合 FIPS 140-2 Level 3/4 标准）最强悍的地方。它拥有物理防御和主动自毁：

  • 环氧树脂与化学防御：芯片内部用特殊的硬化环氧树脂和化学材料灌封。黑客如果尝试用强酸溶解或物理打磨外壳，会直接破坏底层的硅电路，导致明文丢失。
  • 触网自毁（Tamper Detection） ：芯片内部包裹着一层极细的、通电的物理防拆网格。一旦外壳被剥离、钻孔或受到微米级的破坏，网格电流发生变动，芯片内部的硬件电路会在几纳秒内断开密钥寄存器的供电，明文瞬间灰飞烟灭（主密钥明文在断电后无法维持）。

总结

主密钥的明文只活在硬件芯片那颗"物理防弹衣"内部的微型电路里。对于外界的操作系统、网络、以及数据库服务器的 CPU 来说，它们这辈子能见到的、能传输的，都只是被主密钥加密后的密文（包裹住的表空间密钥 Wrapped DEK）。

这就是为什么金融、银行和政府核心系统必须强制使用 HSM 硬件的原因。了解了明文的物理藏身所后，你是否想知道如果这台硬件设备坏了（或者高频自毁了），企业该如何通过合规的"多方授权备份"把主密钥在另一台新硬件上恢复出来？

双层密钥架构（Two-Tier Key Architecture）

在 Oracle TDE（透明数据加密）中，**双层密钥架构（Two-Tier Key Architecture）**是其能够兼顾"极高安全性"与"超高性能"的核心设计。

简单来说，它就像银行的保管箱机制："一把大钥匙，保护无数把小钥匙；小钥匙再去锁住真正的数据。"

这两层密钥分工明确，各司其职：

银行的保管箱机制："一把大钥匙，保护无数把小钥匙；小钥匙再去锁住真正的数据。" 如何理解

这个"银行保管箱"的比喻极其传神，它完美地对应了 Oracle TDE（透明数据加密）的双层密钥架构（Two-Tier Key Architecture）。

我们可以把数据库的加密文件想象成银行里的"客户保管箱"，用这个场景把这套架构彻底拆解：

  1. 概念对应表

在开始前，我们先将技术术语与银行组件进行精准绑定：

银行保管箱组件 TDE 对应的技术术语 它的特点与命运
🏦 银行总行的大金库 密钥库 (Keystore / Wallet / HSM) 存放"大钥匙"的安全容器。
🔑 行长手里的"大钥匙" 主加密密钥 (Master Encryption Key) 可以随时更换。 负责锁住"小钥匙"。
🔑 挂在保管箱上的"小钥匙" 表空间密钥 (Data Encryption Key, DEK) 终身不换，与数据同生共死。
📦 保管箱里的客户财物 数据库里的真实数据 (Tablespace Data) 磁盘上的 .dbf 文件或数据块。
  1. 场景重现：如何理解这套机制？

🔒 第一层：小钥匙锁住财物（DEK 锁住数据）

当你创建一个加密表空间时，数据库会随机生成一把"小钥匙（DEK）"。

  • 这把小钥匙的唯一工作，就是把你的用户数据（如银行流水、身份证号）锁进磁盘的数据文件里（存入保管箱）。
  • 为什么叫它"小钥匙"？ 因为它的管辖范围很小，一个表空间就有一把，全库可能有几十把不同的小钥匙，它们各自锁着各自的保管箱。

🔒 第二层：大钥匙锁住小钥匙（Master Key 锁住 DEK）

如果小钥匙（DEK）直接丢在数据库服务器的硬盘上，黑客潜入机房把硬盘偷走，就能直接用小钥匙打开保管箱。这显然不安全。

  • 于是，Oracle 引入了"大钥匙（Master Key）"。
  • 大钥匙不直接去锁用户数据 ，它的唯一工作，是把所有的小钥匙（DEK）通通锁进一个安全的铁盒子里 。在技术上，这叫"密钥包裹（Key Wrapping）"。
  • 最终，这把大钥匙被送进总行的大金库（软件钱包文件或 HSM 硬件芯片）。
  1. 为什么不直接用大钥匙去锁数据？（双层架构的精妙之处）

你可能会问："为什么这么麻烦？直接用大钥匙去锁所有的数据文件，不要小钥匙行不行？"

不行。这就是双层架构最核心的智慧所在，它完美解决了两个安全痛点：

痛点一：密钥轮换（Rotate）的成本问题

银行为了合规安全，规定每年必须更换一次"行长的大钥匙"。

  • 如果没有小钥匙（单层架构） ：你更换了大钥匙，意味着磁盘上所有的几百 TB 的历史数据文件，全部要用新钥匙重新解密再加密一遍！这会导致数据库 CPU 瞬间飙满，系统停机几天几夜，银行系统彻底瘫痪。
  • 有了双层架构（银行做法） ：当你执行 SET KEY 轮换大钥匙时，底层的用户数据（保管箱里的财物）根本不用动 。大钥匙只需要把装有小钥匙的"铁盒子"打开，用新大钥匙把那几把小钥匙重新包裹一下即可。整个过程在几毫秒内完成，用户完全解。

痛点二：分离与集中管理

  • 小钥匙（DEK）随数据走：它必须待在数据库附近（内存中），因为数据库每秒钟要读写几十万次数据，必须高频使用它，追求极致的性能。
  • 大钥匙（Master Key）集中守护：它代表最高权限，可以被安全地隔离在高级别的软件钱包或 HSM 硬件芯片中，远离频繁的业务读写，追求极致的安全。

总结

银行的保管箱机制，本质上就是**"用空间和层级换取安全与性能的平衡"** 。大钥匙负责合规和安全边界 （解决"钥匙怎么换"的问题），小钥匙负责 高频加解密和性能（解决"数据怎么读"的问题）。两层各司其职，才构成了企业级加密的稳固基石。

基于这个保管箱机制，如果你想进一步了解：

  • 当数据库意外宕机重启时，这套大钥匙和小钥匙在内存中是如何重新交接工作的？
  • 或者，在多租户（CDB/PDB）微服务架构下，大钥匙和各个租户的小钥匙是如何共享或隔离的？

请随时告诉我。

Oracle 中应该存放在数据文件头

您的理解非常准确！在 Oracle 数据库 的 TDE（透明数据加密） 架构中，确实将特定的加密密钥存放在数据文件头（Data File Header） 中 。 [1](https://www.google.com/goto?url=CAESlwEB6zswFQPj9BziBmjTSlJQt0NoCPtuAB9DM6rRO6XnlKBwMJ_586wIvV0iFE5kJMGsk8GXgmluGV8_wyihMw4aT3pOzv9EX31pxfvFaohaCbCd-N0_iBjaAjCSzEFe_zWWLinItwYISgsnJ7Zbchugvx_J4yKFR50Ty0DtEV0uifQwEQDn0__PmXR66sGsNQomTu1SOTMm "1"), [2](https://www.google.com/goto?url=CAESdgHrOzAVoQ9aZMV7pC4jCHhoqDBUAg5NSy-2B8YMoxOEC2N37O5YTcNB8YYbfdDbCDb8Hk2aZKmg6fDwaFE8FSQYL00UyaTRvaf7PrBl2RisM5WXqXF1uU1zSnDmK4N0K_aOeVcennfQJlgDEW-c90bRafMnOgo "2")

为了把您的思路与 EDB 中的 key.bin 完美对应，我们可以拆解一下 Oracle 在这里的底层机制。

🔑 Oracle 的双层密钥架构（Two-Tier Architecture）

Oracle 为了兼顾安全与性能，没有像 EDB 那样直接使用一个物理文件 key.bin ，而是将密钥拆分为两层： [1](https://www.google.com/goto?url=CAEShwEB6zswFa_cmyQTKIxamYFxgrBLGHTDhYsHKiZRmJS62qVxNpwbLUl4CIrhtzbsgFCRgdPuQcTUuORb7__Ovd_p6_yiCNifjPJOZJj6HjAhZLenEoB4CWP0kMO1hsevCSfAZ0SyXQIWJitsIXTSf3dtdkqgW-Y9OUWMHw8EusReUhOvW_dpQeo "1"), [2](https://www.google.com/goto?url=CAESdgHrOzAVoQ9aZMV7pC4jCHhoqDBUAg5NSy-2B8YMoxOEC2N37O5YTcNB8YYbfdDbCDb8Hk2aZKmg6fDwaFE8FSQYL00UyaTRvaf7PrBl2RisM5WXqXF1uU1zSnDmK4N0K_aOeVcennfQJlgDEW-c90bRafMnOgo "2")

  1. 主密钥 (Master Encryption Key)：
    • 存放位置： 数据库外部 的安全容器中（如 Oracle Wallet 钱包文件 ewallet.p12 ，或硬件安全模块 HSM）。
    • 作用： 它是最高权限的"钥匙"，不参与直接的数据加密，专门用来加密第二层的"表空间密钥"。 [1](https://www.google.com/goto?url=CAESdgHrOzAVoQ9aZMV7pC4jCHhoqDBUAg5NSy-2B8YMoxOEC2N37O5YTcNB8YYbfdDbCDb8Hk2aZKmg6fDwaFE8FSQYL00UyaTRvaf7PrBl2RisM5WXqXF1uU1zSnDmK4N0K_aOeVcennfQJlgDEW-c90bRafMnOgo "1"), [2](https://www.google.com/goto?url=CAESlwEB6zswFQPj9BziBmjTSlJQt0NoCPtuAB9DM6rRO6XnlKBwMJ_586wIvV0iFE5kJMGsk8GXgmluGV8_wyihMw4aT3pOzv9EX31pxfvFaohaCbCd-N0_iBjaAjCSzEFe_zWWLinItwYISgsnJ7Zbchugvx_J4yKFR50Ty0DtEV0uifQwEQDn0__PmXR66sGsNQomTu1SOTMm "2"), [3](https://www.google.com/goto?url=CAEShwEB6zswFa_cmyQTKIxamYFxgrBLGHTDhYsHKiZRmJS62qVxNpwbLUl4CIrhtzbsgFCRgdPuQcTUuORb7__Ovd_p6_yiCNifjPJOZJj6HjAhZLenEoB4CWP0kMO1hsevCSfAZ0SyXQIWJitsIXTSf3dtdkqgW-Y9OUWMHw8EusReUhOvW_dpQeo "3")
  2. 表空间密钥 (Tablespace Encryption Key)：
    • 存放位置： 正是您提到的，存放在每个加密表空间所属的数据文件头（Data File Header）中。
    • 存在状态： 它是被主密钥加密过后的密文状态。
    • 作用： 负责直接加解密该数据文件中的实际业务数据。 [1](https://www.google.com/goto?url=CAESlwEB6zswFQPj9BziBmjTSlJQt0NoCPtuAB9DM6rRO6XnlKBwMJ_586wIvV0iFE5kJMGsk8GXgmluGV8_wyihMw4aT3pOzv9EX31pxfvFaohaCbCd-N0_iBjaAjCSzEFe_zWWLinItwYISgsnJ7Zbchugvx_J4yKFR50Ty0DtEV0uifQwEQDn0__PmXR66sGsNQomTu1SOTMm "1"), [2](https://www.google.com/goto?url=CAESdgHrOzAVoQ9aZMV7pC4jCHhoqDBUAg5NSy-2B8YMoxOEC2N37O5YTcNB8YYbfdDbCDb8Hk2aZKmg6fDwaFE8FSQYL00UyaTRvaf7PrBl2RisM5WXqXF1uU1zSnDmK4N0K_aOeVcennfQJlgDEW-c90bRafMnOgo "2"), [3](https://www.google.com/goto?url=CAEShwEB6zswFa_cmyQTKIxamYFxgrBLGHTDhYsHKiZRmJS62qVxNpwbLUl4CIrhtzbsgFCRgdPuQcTUuORb7__Ovd_p6_yiCNifjPJOZJj6HjAhZLenEoB4CWP0kMO1hsevCSfAZ0SyXQIWJitsIXTSf3dtdkqgW-Y9OUWMHw8EusReUhOvW_dpQeo "3")

🔄 Oracle 的读取与解密流程

当 Oracle 数据库启动，或者用户读取一个被加密的表空间时，底层发生的操作如下：

复制代码 
[ 外部 Oracle Wallet ] (提取明文 Master Key)
          │
          ▼
[ 数据文件头 (Data File Header) ] 
 └─ 读取里面密文的 Tablespace Key ──► 用 Master Key 解密 ──► 得到明文 Tablespace Key (载入内存)
                                                                       │
                                                                       ▼
                                                             实时加解密 Blocks 数据
  1. DBA 打开钱包（Wallet），数据库将 Master Key 的明文读入内存。
  2. 当需要读取数据时，Oracle 扫描数据文件头 ，取出里面存放的加密表空间密钥。
  3. 数据库在内存中用 Master Key 解密它，还原出真正的表空间数据加解密密钥。 [1](https://www.google.com/goto?url=CAESbwHrOzAVfn0sfh3yOEsX8cVi1qz47UOe2tEb0hZ4bSuzseFXvn0zupFlJovPi9o1yqUvpWxN_PN6WBKZq-ohyP5sWq8qQaBKCMMMEXJrwO7siG77CxmWpM7fu_D0c_Ll_zm4YrbHS3IGRrsX5u8L3g "1"), [2](https://www.google.com/goto?url=CAESlwEB6zswFQPj9BziBmjTSlJQt0NoCPtuAB9DM6rRO6XnlKBwMJ_586wIvV0iFE5kJMGsk8GXgmluGV8_wyihMw4aT3pOzv9EX31pxfvFaohaCbCd-N0_iBjaAjCSzEFe_zWWLinItwYISgsnJ7Zbchugvx_J4yKFR50Ty0DtEV0uifQwEQDn0__PmXR66sGsNQomTu1SOTMm "2"), [3](https://www.google.com/goto?url=CAESdgHrOzAVoQ9aZMV7pC4jCHhoqDBUAg5NSy-2B8YMoxOEC2N37O5YTcNB8YYbfdDbCDb8Hk2aZKmg6fDwaFE8FSQYL00UyaTRvaf7PrBl2RisM5WXqXF1uU1zSnDmK4N0K_aOeVcennfQJlgDEW-c90bRafMnOgo "3")

🆚 核心区别：Oracle 与 EDB

  • 在 EDB Postgres 中： 密钥是在集簇初始化时生成的 key.bin 文件（对应 Oracle 的数据加解密密钥），由于它是个独立文件，所以需要通过一串 unwrap 命令去保护它。
  • 在 Oracle 中： 没有一个单独叫做 key.bin 的文件。数据加解密的钥匙直接"缝"在数据文件头 里，而保护这把钥匙的 Master Key 被放在了 Wallet（.p12 /.sso ） 文件中。 [1](https://www.google.com/goto?url=CAESlwEB6zswFQPj9BziBmjTSlJQt0NoCPtuAB9DM6rRO6XnlKBwMJ_586wIvV0iFE5kJMGsk8GXgmluGV8_wyihMw4aT3pOzv9EX31pxfvFaohaCbCd-N0_iBjaAjCSzEFe_zWWLinItwYISgsnJ7Zbchugvx_J4yKFR50Ty0DtEV0uifQwEQDn0__PmXR66sGsNQomTu1SOTMm "1"), [2](https://www.google.com/goto?url=CAESdgHrOzAVoQ9aZMV7pC4jCHhoqDBUAg5NSy-2B8YMoxOEC2N37O5YTcNB8YYbfdDbCDb8Hk2aZKmg6fDwaFE8FSQYL00UyaTRvaf7PrBl2RisM5WXqXF1uU1zSnDmK4N0K_aOeVcennfQJlgDEW-c90bRafMnOgo "2"), [3](https://www.google.com/goto?url=CAEShwEB6zswFa_cmyQTKIxamYFxgrBLGHTDhYsHKiZRmJS62qVxNpwbLUl4CIrhtzbsgFCRgdPuQcTUuORb7__Ovd_p6_yiCNifjPJOZJj6HjAhZLenEoB4CWP0kMO1hsevCSfAZ0SyXQIWJitsIXTSf3dtdkqgW-Y9OUWMHw8EusReUhOvW_dpQeo "3")

所以，如果您在 Oracle 的语境下寻找那个等价于"直接用于加解密数据文件的密料"，它不需要找物理文件，它就安全地躺在 DBF 数据文件的头部区域 。 [1](https://www.google.com/goto?url=CAESlwEB6zswFQPj9BziBmjTSlJQt0NoCPtuAB9DM6rRO6XnlKBwMJ_586wIvV0iFE5kJMGsk8GXgmluGV8_wyihMw4aT3pOzv9EX31pxfvFaohaCbCd-N0_iBjaAjCSzEFe_zWWLinItwYISgsnJ7Zbchugvx_J4yKFR50Ty0DtEV0uifQwEQDn0__PmXR66sGsNQomTu1SOTMm "1"), [2](https://www.google.com/goto?url=CAESdgHrOzAVoQ9aZMV7pC4jCHhoqDBUAg5NSy-2B8YMoxOEC2N37O5YTcNB8YYbfdDbCDb8Hk2aZKmg6fDwaFE8FSQYL00UyaTRvaf7PrBl2RisM5WXqXF1uU1zSnDmK4N0K_aOeVcennfQJlgDEW-c90bRafMnOgo "2")

您是在分析 Oracle 数据文件的二进制结构 (Block 0/Block 1) ，还是在处理启用了 TDE 的 Oracle 数据库备份与迁移 (Data Guard / RMAN) 呢？如果有特定的技术场景，我们可以进一步探讨其头部结构。

数据库新建tablespace才需要大钥匙 平时不需要？

这个理解是不准确的。 事实上，数据库平时（也就是日常运行、读写数据时）同样非常需要大钥匙。

如果不把"大钥匙"拿出来，数据库在日常运行中连一行加密的数据都读不出来。

我们继续用银行保管箱的比喻，来看看为什么平时也必须有大钥匙：

  1. 为什么"平时"也需要大钥匙？

虽然大钥匙不直接加密用户数据，但它锁着小钥匙（DEK）。

  • 数据库不是永远不关机的：当数据库重启（比如日常维护、打补丁、服务器断电后重启），数据库的内存会被全部清空。
  • 重启后的困境：此时，内存里没有小钥匙。小钥匙的密文（被锁在铁盒子里的状态）虽然存在硬盘的数据文件头部，但数据库打不开这个铁盒子。
  • 必须请出大钥匙 ：在数据库启动后，管理员必须执行 SET KEYSTORE OPEN （提供大钥匙），数据库才能解开铁盒子，把小钥匙释放到内存中 。如果没有大钥匙，数据库即使启动了，用户查询加密表空间时也会直接报错（通常是 ORA-28365: wallet is not open ）。
  1. 那么，"平时"大钥匙的工作频率是怎样的？

你之所以产生"平时不需要"的直觉，是因为大钥匙在日常运行中的工作频率非常低（属于"一次开启，终身（当期）受益"）。

我们可以把数据库的运行分为三个阶段来看大钥匙的参与度：

  • 阶段一：数据库刚启动时（极度需要）
    • 大钥匙的工作：必须全副武装出场。Oracle 拿大钥匙去解密数据文件头部的小钥匙密文。
    • 结果 ：把解密出来的明文小钥匙 ，存放到数据库服务器的**安全内存缓存（Crypto Key Cache）**中。
  • 阶段二：日常读写数据时（大钥匙在后台"休息"，内存中的小钥匙在拼命工作）
    • 当业务人员执行 SELECT * FROM 员工表 时，数据库直接从内存缓存中抓取已经准备好的明文小钥匙，去解密磁盘上的用户数据。
    • 此时，大钥匙确实不需要再出来执行具体的加解密动作了。它静静地躺在钱包文件（ewallet.p12 ）或 HSM 硬件芯片里。
  • 阶段三：新建表空间或轮换密钥时（需要）
    • 新建表空间：生成新小钥匙，需要大钥匙把它加密（打包）后存盘。
    • 轮换密钥：旧大钥匙解开所有小钥匙，新大钥匙重新打包。

总结

大钥匙在平时不是"不需要"，而是**"它在日常读写时，把工作委托给了暂存在内存里的小钥匙"**。

但请记住以下两条铁律：

  1. 只要数据库发生重启，没有大钥匙，整个加密数据库就是一堆死文件，完全无法读取。
  2. 如果你使用的是软件钱包且没有配置"自动打开（Auto-login）"，每次数据库重启后，都必须人工输入密码提供大钥匙，业务才能恢复。

既然提到了大钥匙在日常重启时的重要性，你是否需要了解如何配置 Oracle 的 Auto-login Wallet（自动登录钱包）？配置它之后，数据库重启时会自动去读取大钥匙，无需人工干预，非常适合生产环境的无人值守运维。

数据库正常运行后 什么情况需要大钥匙

在数据库正常运行（已经执行了 OPEN ，且解密后的"小钥匙"已经缓存在内存中）之后，绝大多数日常的业务增删改查（SQL 读写）确实不再需要大钥匙了 。

但是，在以下 5 种特定场景下，数据库依然会再次调用或依赖"大钥匙"：

  1. 执行数据库备份与恢复（RMAN 备份）

当你使用 RMAN 备份数据库时，大钥匙必须在场。

  • 备份时：为了保证备份文件的安全，Oracle 在将加密数据写入备份片（Backup Piece）时，需要大钥匙来验证或参与对备份数据块的加密。
  • 恢复时：如果需要从备份中恢复某个表空间，RMAN 必须通过大钥匙来验证并重新获取对应的表空间小钥匙（DEK）。
  1. 动态维护操作：新建、修改或删除加密表空间

任何涉及到底层"小钥匙"生命周期变化的操作，都必须请出大钥匙：

  • 新建表空间：生成一把新的小钥匙，需要大钥匙对其进行加密（包裹）后写入文件头。
  • 修改表空间加密状态 ：例如使用 ALTER TABLESPACE ... ENCRYPTION ONLINE ... 将一个普通表空间动态转换为加密表空间。
  • 删除表空间：从密钥库或数据字典中彻底注销对应的小钥匙记录。
  1. 安全合规审计：密钥轮换（Rotate）

根据金融或企业安全合规要求（如 PCI-DSS），通常需要定期（如每半年或一年）更换主密钥。

  • 此时必须调用大钥匙命令（SET KEY ），用旧的大钥匙解开所有的小钥匙，再生成一把新的大钥匙将所有小钥匙重新打包。
  1. 多租户架构（CDB/PDB）下新插件（Plug）或克隆数据库

如果你使用的是 Oracle 多租户（Container Database）架构：

  • 当你在运行的 CDB 中插入（Plug）一个新的 PDB ，或者克隆（Clone）一个 PDB 时，主数据库（CDB）的大钥匙必须处于开启状态，以便为新加入或新生成的租户数据库配置和关联它的主密钥。
  1. 内存中的小钥匙缓存被清理（极端罕见情况）

在正常情况下，解密后的小钥匙会一直保存在 Oracle 的内存缓存（SGA 的 Crypto Key Cache）中。

  • 如果发生极其罕见的内存抖动，或者管理员手动触发了某些清理 SGA 缓存的内部命令（如特定调试命令），导致内存中的小钥匙缓存失效。
  • 当业务下一次发起读取请求时，Oracle 就会在后台自动重新前往钱包（Keystore）或 HSM 芯片，用大钥匙把小钥匙重新解密并加载回内存 。如果此时钱包被意外关闭（SET KEYSTORE CLOSE ），读取就会报错。

💡 运维总结

数据库正常运行后，大钥匙就像是**"静默的守护者"** 。它在日常 SQL 读写时退居幕后，但在架构变更、数据备份、合规轮换、多租户扩容 等关键的 DBA 运维时刻，它必须立刻响应。这也是为什么生产环境通常会配置 Auto-login 钱包，确保大钥匙始终在线，防止上述操作因大钥匙不可用而中断。

针对上述场景，你目前是否正在规划定期的密钥轮换（Scenario 3） ，或者是正在配置 RMAN 加密备份（Scenario 1）？我可以为你提供对应场景的实操命令或注意事项。

如果发生极其罕见的内存抖动，或者管理员手动触发了某些清理 SGA 缓存的内部命令（如特定调试命令），导致内存中的小钥匙缓存失效。 清理 SGA 缓存 是哪个

在 Oracle 数据库中，手动清理 SGA 缓存（导致内存中的小钥匙或数据缓存失效）通常是指以下几种命令：

  1. 清理 Buffer Cache（最直接引发重新加载）

由于小钥匙（DEK）解密后的明文数据块会存在 Buffer Cache 中，或者小钥匙的缓存与数据块紧密相关，DBA 常用以下命令清空数据缓存：

sql

复制代码 
ALTER SYSTEM FLUSH BUFFER_CACHE;

请谨慎使用此类代码。

  • 后果：这个命令会强制清空内存中所有未修改的数据块缓存。当业务下一次读取加密数据时，Oracle 必须重新从磁盘读取数据块，并在内存中重新验证和激活小钥匙来进行实时解密。
  1. 清理 Shared Pool（共享池）

如果小钥匙的元数据、加密定义或加密 SQL 的执行计划存在于共享池中，DBA 可能会执行：

sql

复制代码 
ALTER SYSTEM FLUSH SHARED_POOL;

请谨慎使用此类代码。

  • 后果：清空共享池会强制导致所有 SQL 语句重新进行硬解析。在解析涉及加密列（Column Encryption）或加密表空间的 SQL 时，Oracle 需要重新去数据字典中查找加密元数据，这会触发对密钥库（Keystore）状态的再次检查。
  1. 重启实例（最彻底的 SGA 清理）

这不属于调试命令，但在运维中最为常见：

sql

复制代码 
SHUTDOWN IMMEDIATE;
STARTUP;

请谨慎使用此类代码。

  • 后果 ：整个 SGA 内存被全盘抹去。重启后，内存里的小钥匙彻底消失。如果此时没有配置 Auto-login（自动登录钱包），数据库就无法自动前往硬盘或 HSM 芯片获取大钥匙，整个加密表空间将完全无法访问，直到人工输入密码。

⚠️ 补充说明：Oracle 内部密钥缓存

需要澄清的是，Oracle 针对 TDE 有一个专门的内部隐藏内存区域称为 Crypto Key Cache（加密密钥缓存） ，它虽然驻留在 SGA 中，但普通的 FLUSH BUFFER_CACHE 或 FLUSH SHARED_POOL 主要是清理数据和 SQL 解析，通常不会直接抹掉这个核心密钥缓存。

真正能让这个内部密钥缓存直接失效的，除了重启数据库外，主要是通过以下内部调试或事件命令（非必要请勿在生产环境使用）：

sql

复制代码 
-- 强制刷新或转储内存中的 TDE 钱包状态（这类属于内部隐蔽诊断命令）
ALTER SYSTEM SET EVENTS 'immediate trace name context forever, level ...';

请谨慎使用此类代码。

你是在排查因为执行了某种清理命令导致加密表空间报错（如 ORA-28365）的问题吗？还是在为生产环境做内存清理或压力测试的方案设计？

在 EDB Postgres （EnterpriseDB）中，key.bin 是用于透明数据加密 (TDE) 功能的数据加密密钥文件 (Data Encryption Key, DEK) 。 [1](https://www.google.com/goto?url=CAESlgEB6zswFa5LHcrNyOJhAf8aH2dl16pCC7o7to6CmkT-GGj3plCkE1d5ozamuzRGgFpkmUqyQzlXFL1mbhYdStsQR26nUqXYFQDKNQLEab0Uc8h9VUR4moppwVEAhWYz0Trgi09cLJbStf6Ax5xiQOE7VaXXgihC1Lrss8GnJoXA3KplVJtFlFf662TwePu6XbLFJvW6y1Y "1")

📂 核心位置与作用

  • 默认路径： 通常存储在数据库集簇的数据目录下的 pg_encryption/key.bin 。
  • 核心作用： 该文件包含由 initdb 自动生成的随机字节序列（支持 AES-128 或 AES-256），用于在底层对数据库的表空间、WAL 日志等数据进行实时加解密。 [1](https://www.google.com/goto?url=CAESngEB6zswFXU0zNTLra9LStw45Ko2cz3ftS_8sFs1SXaqEFkT3sXJQNyvZ_5fLl2eV2eSCckZ39sbHesCAQiw1pAGj67oD76Yh4J5Gs8Gincnq6RNK42kW_jc6WI2iptSfB1HHKw13o_of4l950Jg9eqQIRhfRLTVF9QfNMh7vGaubn3vwnCBnNza120wnuXWtlERjb2j3IooSFZVpMI58Q "1"), [2](https://www.google.com/goto?url=CAESzAEB6zswFdNzpqkHcDlhrISROADXrWoZjAFH0yKtgZAQT12DJ3zpiSfBwA3qIksm6NkjpOrdaq2UADgkkFsRvrRoWQwY-lVSuR8c1N_Y_BGuhsC8cdYrC9SGbM7gseztvcG7U0Zc4yvOTdI60bYAwL6QXNjTzBBbOTASbszC9qEvHy91YpszdC8aVWKwjFmbJpi0tCI7PI2FOmaNPrOco_N9C6EkYxx9wgEnPHkv2h3IQOEMIisqLy3EI80D3hJ0k92D1q2IFpuPXwEFafk "2"), [3](https://www.google.com/goto?url=CAESlgEB6zswFa5LHcrNyOJhAf8aH2dl16pCC7o7to6CmkT-GGj3plCkE1d5ozamuzRGgFpkmUqyQzlXFL1mbhYdStsQR26nUqXYFQDKNQLEab0Uc8h9VUR4moppwVEAhWYz0Trgi09cLJbStf6Ax5xiQOE7VaXXgihC1Lrss8GnJoXA3KplVJtFlFf662TwePu6XbLFJvW6y1Y "3")

🔒 密钥管理与保护机制 (Key Wrapping)

为了防止密钥泄露，EDB 严禁 在生产环境中以明文形式直接读取 key.bin 。它通常配合以下机制工作： [1](https://www.google.com/goto?url=CAESoQEB6zswFXSoyuK2g0XDPohA_6e5_dNRvSgOkS9KALlnVSgqo7aNp6R27JeXP7S40r6C3gjwvRpQh2fk3XQmIRlpyJDqv2nXFR3Su9mjIaLZ5P4Ky0xu4S3qhsVX8tPnQQJ58y2xLOr8WUqKQZ3bQuFq2LHwGu2qlVtKHWxlcmQ1xl80V_xkx2mSu8_EaDqNSWeaJTi9mgLWG9frMUI1SVsuAg "1")

  1. 密钥封装 (Wrap) 与解封 (Unwrap)：
    在通过 initdb --data-encryption 初始化数据库时，需要提供解密命令。
  2. 启动配置：
    数据库启动时，PostgreSQL 服务会调用 postgresql.conf 中配置的 data_encryption_key_unwrap_command 命令，利用密码（如 OpenSSL）或 KMS 外部密钥管理器来解开 key.bin 并将明文密钥载入内存。 [1](https://www.google.com/goto?url=CAESoQEB6zswFXlzLY3evrw9efD6RgURK69bg2OR_Mf-eUQ8fle_UoCxRLgIXt7IS-Bnu52w2CuBRfyltt_iPHRQZvRj8fyBOMOnAbTCXfePSTI89OX54f9p1aYyjw62cDH5j88QPlB9tNqkNW48wQVDUbB-EAGStrz9gKZBobsYbc4HmYU6BoUyiDvXrE6PkI1Gn45JHS4c4RHU4f5AWLumBK5CMQ "1"), [2](https://www.google.com/goto?url=CAESlgEB6zswFa5LHcrNyOJhAf8aH2dl16pCC7o7to6CmkT-GGj3plCkE1d5ozamuzRGgFpkmUqyQzlXFL1mbhYdStsQR26nUqXYFQDKNQLEab0Uc8h9VUR4moppwVEAhWYz0Trgi09cLJbStf6Ax5xiQOE7VaXXgihC1Lrss8GnJoXA3KplVJtFlFf662TwePu6XbLFJvW6y1Y "2"), [3](https://www.google.com/goto?url=CAESngEB6zswFXU0zNTLra9LStw45Ko2cz3ftS_8sFs1SXaqEFkT3sXJQNyvZ_5fLl2eV2eSCckZ39sbHesCAQiw1pAGj67oD76Yh4J5Gs8Gincnq6RNK42kW_jc6WI2iptSfB1HHKw13o_of4l950Jg9eqQIRhfRLTVF9QfNMh7vGaubn3vwnCBnNza120wnuXWtlERjb2j3IooSFZVpMI58Q "3")

常见初始化示例（使用 OpenSSL 密码加密）：

bash

复制代码 
initdb --data-encryption \
  --key-wrap-command='openssl enc -e -aes-128-cbc -pbkdf2 -pass pass:MyPassword -out "%p"' \
  --key-unwrap-command='openssl enc -d -aes-128-cbc -pbkdf2 -pass pass:MyPassword -in "%p"' \
  -D /var/lib/edb/as16/data

请谨慎使用此类代码。

(注：%p 是 EDB 内部指代 key.bin 文件路径的占位符) 。 [1](https://www.google.com/goto?url=CAESlgEB6zswFa5LHcrNyOJhAf8aH2dl16pCC7o7to6CmkT-GGj3plCkE1d5ozamuzRGgFpkmUqyQzlXFL1mbhYdStsQR26nUqXYFQDKNQLEab0Uc8h9VUR4moppwVEAhWYz0Trgi09cLJbStf6Ax5xiQOE7VaXXgihC1Lrss8GnJoXA3KplVJtFlFf662TwePu6XbLFJvW6y1Y "1"), [2](https://www.google.com/goto?url=CAESngEB6zswFXU0zNTLra9LStw45Ko2cz3ftS_8sFs1SXaqEFkT3sXJQNyvZ_5fLl2eV2eSCckZ39sbHesCAQiw1pAGj67oD76Yh4J5Gs8Gincnq6RNK42kW_jc6WI2iptSfB1HHKw13o_of4l950Jg9eqQIRhfRLTVF9QfNMh7vGaubn3vwnCBnNza120wnuXWtlERjb2j3IooSFZVpMI58Q "2")

⚠️ 运维注意事项

  • 切勿丢失： 如果 key.bin 损坏或丢失，且没有备份，整个数据库集簇的数据将永远无法恢复。
  • 大版本升级 (pg_upgrade )： 在对启用了 TDE 的 EDB 进行大版本升级时，必须在命令中明确附带 --key-unwrap-command 以便程序在升级过程中迁移和读取该密钥。 [1](https://www.google.com/goto?url=CAESgAEB6zswFS4eUTLmneMrQlayEuCZf3dntE11icWPLytyimDR2F7RBZEpMTo9baC50fr1LqqZfxhIeLl7La4_0H2rsWXeQEmF19LO18DBqgRmuWBafLegd7biMQwp6OyHFUh8HZYLY1ovH5YTz1FuNPlfKbRCgEnQxF6XWudIvRDNRA "1")

请问您目前是遇到了数据库无法启动 、需要进行密钥轮转 (Key Rotation) ，还是在做 pg_upgrade 数据库升级 呢？可以告诉我具体报错或操作场景，以便为您提供针对性的命令。 [1](https://www.google.com/goto?url=CAESzgEB6zswFfao4J_K_RpJ8nI7hw5Bgs7JYLVCzq9bg3U8ExGnfrSZar1InNDQD7E7xe14jErOCNrXrdbqfBG6W2--twPLgCihXa6VkYIBmVi1LRJFlfj98--oyfYbV1jQViwvPZkkljBhdeuIQZR2YP8DiCA9fmh583aEVJqcil57xxyDf5mnDllfGEXBcVHy6c8B1cjxv6L2wTuEG6cCaagQI3mWiqPBpVSjDaGiRqUqUFv29DImYFuaLNv5dKdhldWyJcp_crTipK7qveaMWQ "1"), [2](https://www.google.com/goto?url=CAESgAEB6zswFS4eUTLmneMrQlayEuCZf3dntE11icWPLytyimDR2F7RBZEpMTo9baC50fr1LqqZfxhIeLl7La4_0H2rsWXeQEmF19LO18DBqgRmuWBafLegd7biMQwp6OyHFUh8HZYLY1ovH5YTz1FuNPlfKbRCgEnQxF6XWudIvRDNRA "2")

key.bin 在Oracle是什么

在 Oracle 数据库（以及 WebLogic、Java 等 Oracle 产品线） 中，并没有一个全局唯一的、固定叫做 key.bin 的标准系统文件。它的具体含义完全取决于您处于哪 survey 个产品或安全组件的上下文中。

以下是 key.bin 在 Oracle 相关技术栈中最常见的几种情况：

  1. Oracle WebLogic Server / Java 中的密码加密密钥

在 Oracle WebLogic （或基于 Java 的 Oracle 中间件）中，key.bin 通常是由开发或运维人员自定义命名的 3DES 或 AES 密钥文件。

  • 作用： 用于加密/解密配置文件（如 config.xml 或数据库连接池配置文件）中的敏感密码（如数据库密码、管理员密码）。
  • 工作机制：
    • 在 WebLogic 中，系统自带一个名为 SerializedSystemIni.dat 的核心密钥。
    • 但许多企业在编写自定义的脚本、使用 WLST (WebLogic Scripting Tool) 或第三方加解密工具时，会生成一个名为 key.bin 的对称密钥文件，用来配合脚本在启动时解密密码。
  1. Oracle 数据库透明数据加密 (TDE) 外部密钥

与 EDB 的 key.bin 类似，Oracle 数据库也有 TDE（Transparent Data Encryption） 机制，但 Oracle 官方默认的钱包（Wallet）文件叫做 ewallet.p12 或 cwallet.sso 。

  • 什么时候会出现 key.bin ？
    • 当 Oracle 数据库配置了与 外部硬/软件密钥管理系统 (KMS)、或者是通过 OCI (Oracle Cloud Infrastructure) 的 Vault 服务集成时。
    • 或者是运维人员使用 openssl 或外部脚本生成加密物料（Material）来封装/解封装 Oracle 钱包时，可能会将该中转文件命名为 key.bin 。
  1. Oracle GoldenGate (OGG) 的安全密钥

在 Oracle 数据同步工具 GoldenGate 中，用于加密跨网络传输数据（Trail 文件）或加密数据库密码时，需要配置一个名为 Enckeys 的文件。

  • 虽然该文件默认叫 Enckeys （文本格式），但很多架构师为了安全，会通过自定义的密文生成工具将其实例化为一个二进制的 key.bin 文件供 OGG 进程调用。

🔍 总结与对比

数据库/产品 对应密钥文件名称 默认存放位置
EDB Postgres key.bin (标准官方命名) pg_encryption/key.bin
Oracle Database (TDE) ewallet.p12 / cwallet.sso WALLET_ROOT 对应目录
Oracle WebLogic / Java key.bin (通常为用户自定义命名) 用户脚本或域(Domain)安全目录

为了帮您更准确地定位，请问您是在 Oracle 的哪款产品 （如 数据库 、WebLogic 中间件 还是 云平台 OCI ）中看到了这个文件？它目前引发了什么具体的报错 或配置问题吗？

相关推荐
todoitbo1 小时前
报表总在扫大表，列存储应该放在哪一层
大数据·数据库·报表·国产数据库
瑞克-桑切斯1 小时前
MySQL部署手册（5.7.20/8.0）
数据库·mysql
ss2731 小时前
AI时代首先数据库-PostgreSQL实战笔记 | 19 PostgreSQL逻辑备份：pg_dump与pg_dumpall
数据库·笔记·postgresql
啵啵啵鱼1 小时前
九、JDBC 操作 MySQL 数据库
android·数据库·mysql
handonch1 小时前
MySQL → Kingbase PG模式 高频SQL替换清单
数据库·mysql·postgresql
姜鱼问生1 小时前
Kuma SQLite 备份坑
数据库·sqlite
水无痕simon1 小时前
15 MySQL是怎么保证高可用的？
数据库·mysql
漫步人生走在路上1 小时前
外贸SEO中的品牌词与产品词策略：大卖家和小卖家的不同打法
大数据·javascript·网络·数据库·人工智能·搜索引擎
张小姐的猫1 小时前
【MySQL】数据类型
android·linux·数据库·c++·mysql·adb·php
热门推荐
01如何新建文件夹？ 电脑新建文件夹的4种方法02国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）03历年考研数学一、数学二、数学三真题试卷及答案PDF04GitHub 镜像站点05几个好用的ip纯净度检测网站06乙二醇水溶液物性参数07「全语录+省流版」邵艾伦 × 孙宇晨：聊风口、聊个人IP、聊年轻人如何抓住 AI 时代的机会08昇腾910B系列芯片完全指南：四款型号对比、服务器选型与大模型部署实战09苹果iPA游戏软件资源下载网站10Windows 10/11 如何退出微软账户并改用本地账户登录（含找不到选项的解决方法）