Oracle 19c的TDE仅实现落盘加密，不提供权限隔离——有SELECT权限的用户仍可直接查看明文；真正的数据访问隔离需结合wallet访问控制（如目录权限、ADMINISTER KEY MANAGEMENT权限）与数据库对象权限（GRANT/REVOKE）分层实现。
Oracle 19c 的 TDE 本身不提供权限隔离能力 —— 加密表空间或加密列的数据，只要用户有 SELECT 权限，就能看到明文结果。 这不是配置问题，而是 TDE 的设计定位：它只负责“落盘加密”，不控制“谁能看到明文”。真要隔离敏感数据访问，得靠其他机制配合。
为什么 ALTER TABLESPACE ENCRYPTION 不带来权限控制
TDE 表空间加密后，V$ENCRYPTED_TABLESPACES 显示已启用，但任何能连上数据库、有对应表 SELECT 权限的用户（包括普通业务账号），执行 SELECT * 仍直接返回解密后的明文。数据库在读取数据块时自动解密，整个过程对 SQL 层完全透明。
- TDE 不改变对象权限模型：它不新增
ENCRYPTED_ACCESS这类系统权限，也不限制已有权限的生效范围 - 加密密钥由 wallet 管理，wallet 打开后，所有会话共享该密钥上下文；没有 per-user 密钥隔离机制
- 即使关闭 wallet（
ALTER SYSTEM SET ENCRYPTION WALLET CLOSE），已建立的连接仍可继续查加密表空间里的数据（直到下次物理读新块）——这进一步说明权限和加密状态是解耦的
真正起隔离作用的是 wallet 访问控制 + 数据库权限组合
所谓“TDE 权限隔离”，实际是把 wallet 的访问门槛和数据库对象权限分层叠加：
- wallet 文件目录（如
/opt/oracle/admin/orcl/wallet）必须设为chmod 700，且属主为oracle:oinstall—— 这防止非 DBA 用户直接读取ewallet.p12或cwallet.sso - 只有具备
ADMINISTER KEY MANAGEMENT权限的用户（通常是SYS或显式授权账号）才能执行SET KEY、OPEN等 wallet 操作；普通用户连SELECT * FROM V$ENCRYPTION_WALLET都会被拒绝（无视图访问权限） - 业务账号只能通过已授权的表/视图访问数据，而这些对象背后是否落在加密表空间里，对其完全不可见 —— 隔离发生在 SQL 层（GRANT/REVOKE），不在加密层
想让不同用户看到不同加密强度的数据？用列加密 + VPD 或 RLS
如果目标是“财务人员能看到完整身份证号，客服只能看到前3位”，TDE 表空间加密做不到，但可以组合使用：
- 对敏感列单独启用 TDE 列加密：
ALTER TABLE emp MODIFY (id_number ENCRYPT USING 'AES256')—— 注意：这要求列无外键约束，且加密后无法建函数索引 - 再配合 Virtual Private Database（VPD）或 Row Level Security（RLS）策略，在查询时动态重写 SQL，例如对客服角色自动追加
WHERE SUBSTR(id_number, 1, 3) = ...条件 - 或者用 Oracle Data Redaction（非 TDE 组件）实时遮盖输出值，比如配置
DBMS_REDACT.ADD_POLICY对id_number列做 partial redaction
最容易被忽略的一点：TDE 加密后，EXPDP 导出的 dump 文件仍是加密的（需 wallet 才能还原），但如果你用 SQL*Plus 把数据 SPOOL 成文本，导出的就是明文 —— 所谓“隔离”只存在于存储层，一旦数据进入客户端内存或文件系统，TDE 就不再起作用。
