Oracle认证：使用Oracle的TDE特性加密(1)

会计考友 · 发表于 2012-8-4 13:41:06

使用作为 Oracle 高级平安选件（版本 10.2 及更高版本）的一部门惹人的 Oracle 数据库透明数据加密（TDE），可以有选择地对保留在数据库底层数据文件中的敏感数据库数据以及所有下流文件组件（如联机重做日志、归档重做日志和数据库备份）进行加密。 TDE 的根基方针是呵护在这些原始操作系统文件中发现的敏感数据，防止不怀好意的人访谒磁盘或备份磁带时对这些数据进行窥探，然后考试考试还原数据库或扫描原始操作系统文件中的数据，如小我可识别信息或信用卡信息。　　作为我的咨询通例的一部门，我已经实施 TDE 多次。可是，在其一一个比来的合约之前，我一向使用 TDE 对现有表中的新列或属于全新表的列进行加密。在这两种情形下使用 TDE 很是简单，因为方针列为空，是以因为缺乏数据和现有应用轨范相关性而不会涉及较大的风险。
　　我比来实施 TDE 的体验有所分歧。我辅佐一家大型公司对一个已跨越一百万行的表中的现有列进行加密。还有一个依靠于列的关头使命应用轨范，是以，您可以设想一下，在起头工作之前有良多主要的工作要考虑。在 Internet 上搜索可供给经验的近似气象之后，我发现只有几个优异的资本可以辅佐我。
　　本文概述了我在经由过程使用 TDE 对现稀有据进行加密的过程中总结出的经验教训。如不美观您考试考试对现有列数据使用 TDE，我但愿此处供给的信息可辅佐您迅速有用地开展近似工作。
　　确定可能的限制
　　研究客户的系统时，我做的第一件工作就是查找与方针列有关的将禁止我们对列加密的数据模子特征，或者查找可能对现有操作发生负面影响的有关列的事项。钙揭捉究搜罗查找列索引和完整性约束。
　　正如 Oracle 文档明晰声明，当您想对具有索引的某个列进行加密时，需要体味良多限制前提。Oracle 不许可对具有位图索引的列进行加密，这与我们的情形没有慎密亲密关系。可是，方针列具有多个通俗的（B 树）索引。尽管 Oracle 许可对具有通俗索引的列进行加密，可是 Oracle 禁止对索引列进行“salt 措置”加密。Salt 措置经由过程在加密之前向数据添加随机字符串来提高一再数据的平安性，是以窃贼使用模式匹配识别手艺加倍难于破解加密的数据。总而言之，经由这个最初的剖析之后，我们会碰着一种情形，那就是我们可以对列进行加密，但不能进行 salt 措置。
　　对列索引进行剖析后，我本可以到此为止，可是我想回覆的下矣闽问题是“使用这些索引合适吗？”我的思虑过程是这样：如不美观索引没有用，那么我会将其删除，从而削减维护索引条目所必需的系统开销，尤其是考虑到加密的额外承担。要判定索引是否有用，我使用 Oracle 数据库的索引看管特征。我发现，现实上索引正处于使用傍边，是以我们必需对其继续进行维护。
　　接下来，我查看了引用完整性约束前提中是否涉及方针列。因为每个表都具有其自己的加密密钥，是以 Oracle 不许可您使用 TDE 对外键关系中涉及的列进行加密。在我们的情形下，引用完整性约束前提中未涉及方针列。
　　评估机能开销
　　我的客户询问的第一组问题之一就是“TDE 对我的应用轨范的一般机能酉鹏何？”Oracle 文档中有一小部门阐述了一般情形下 TDE 对相关应用轨范机能的影响。可是我的客户但愿获得一些具体的统计信息，以辅佐他们体味 TDE 若何酉耪常进行的有严酷时刻要求的数据加载过程。

　　为了知足客户需求，我计较了天天在有严酷时刻要求的过程中插入到方针表中的平进行数。然后，我在客户端的不异沙箱情形中建树了一个近似的测试表和索引，测量在加密方针列前后插入不异数目的行所破耗的时刻。时刻耗损上的分歧让我们更好地体味了在该过程中对列数据进行加密所造成的“机能损失踪”。列表 1 是我若何使用 SQL*Plus 执行该操作的示例。

会计考友 · 发表于 2012-8-4 13:41:07

</p>　　SQL> CONNECT system
　　Enter password:
　　Connected.
　　SQL> -- Configure Oracle-Managed (Data) Files
　　SQL> ALTER SYSTEM
　　2 SET db_create_file_dest = ’/data01/oracle/’
　　3 SCOPE = MEMORY;
　　System altered.
　　SQL> -- Create two new tablespaces for the demo,
　　SQL> -- one for data segments, one for index segments
　　SQL> CREATE TABLESPACE data_001
　　2 DATAFILE SIZE 1G;
　　Tablespace created.
　　SQL> CREATE TABLESPACE indx_001
　　2 DATAFILE SIZE 500M;
　　Tablespace created.
　　SQL> -- Create a user for the demo
　　SQL> CREATE USER app_001 IDENTIFIED BY app
　　2 DEFAULT TABLESPACE data_001
　　3 TEMPORARY TABLESPACE temp
　　4 QUOTA UNLIMITED ON data_001
　　5 QUOTA UNLIMITED ON indx_001;
　　User created.
　　SQL> GRANT CREATE SESSION, CREATE TABLE TO app_001;
　　Grant succeeded.
　　SQL> -- Work as the demo user
　　SQL> CONNECT app_001/app;
　　Connected.
　　SQL> -- Create the demo table in the default tablespace
　　SQL> CREATE TABLE app_001.transactions (
　　2 trans_id INTEGER
　　3 CONSTRAINT transactions_pk PRIMARY KEY
　　4 USING INDEX TABLESPACE indx_001,
　　5 credit_card INTEGER NOT NULL
　　6 );
　　Table created.
　　SQL> -- Create an index in the INDX_001 tablespace
　　SQL> CREATE INDEX app_001.transactions_ndx1
　　2 ON app_001.transactions(credit_card)
　　3 TABLESPACE indx_001;
　　Index created.
　　SQL> -- Time how long it takes to load data in the clear
　　SQL> SET TIMING ON;
　　SQL> BEGIN
　　2 -- AMEX
　　3 FOR i IN 1 .. 100000 LOOP
　　4 INSERT INTO app_001.transactions(trans_id, credit_card)
　　5 VALUES (
　　6 i,
　　7 ’34’ || TRUNC(DBMS_RANDOM.VALUE(low=>0, high=>99999999999999))
　　8 );
　　9 END LOOP;
　　10 COMMIT;
　　11 -- VISA
　　12 FOR i IN 100001 .. 400000 LOOP
　　13 INSERT INTO app_001.transactions(trans_id, credit_card)
　　14 VALUES (
　　15 i,
　　16 ’4’ || TRUNC(DBMS_RANDOM.VALUE(low=>0, high=>999999999999999))
　　17 );

　　18 END LOOP;

会计考友 · 发表于 2012-8-4 13:41:08

</p>　　19 COMMIT;
　　20 -- MASTERCARD
　　21 FOR i IN 400001 .. 500000 LOOP
　　22 INSERT INTO app_001.transactions(trans_id, credit_card)
　　23 VALUES (
　　24 i,
　　25 ’54’ || TRUNC(DBMS_RANDOM.VALUE(low=>0, high=>99999999999999))
　　26 );
　　27 END LOOP;
　　28 COMMIT;
　　29 END;
　　30 /
　　PL/SQL procedure successfully completed.
　　Elapsed: 00:00:56.14
　　SQL> SET TIMING OFF;
　　SQL> -- Remove existing synthetic data
　　SQL> TRUNCATE TABLE app_001.transactions;
　　Table truncated.
　　SQL> -- Enable encryption of the credit card column
　　SQL> ALTER TABLE app_001.transactions
　　2 MODIFY (credit_card ENCRYPT NO SALT);
　　Table altered.
　　SQL> -- Time how long it takes to load encrypted data
　　SQL> SET TIMING ON;
　　SQL> BEGIN
　　2 -- AMEX
　　3 FOR i IN 1 .. 100000 LOOP
　　4 INSERT INTO app_001.transactions(trans_id, credit_card)
　　5 VALUES (
　　6 i,
　　7 ’34’ || TRUNC(DBMS_RANDOM.VALUE(low=>0, high=>99999999999999))
　　8 );
　　9 END LOOP;
　　10 COMMIT;
　　11 -- VISA
　　12 FOR i IN 100001 .. 400000 LOOP
　　13 INSERT INTO app_001.transactions(trans_id, credit_card)
　　14 VALUES (

　　15 i,

会计考友 · 发表于 2012-8-4 13:41:09

</p>　　16 ’4’ || TRUNC(DBMS_RANDOM.VALUE(low=>0, high=>999999999999999))
　　17 );
　　18 END LOOP;
　　19 COMMIT;
　　20 -- MASTERCARD
　　21 FOR i IN 400001 .. 500000 LOOP
　　22 INSERT INTO app_001.transactions(trans_id, credit_card)
　　23 VALUES (
　　24 i,
　　25 ’54’ || TRUNC(DBMS_RANDOM.VALUE(low=>0, high=>99999999999999))
　　26 );
　　27 END LOOP;
　　28 COMMIT;
　　29 END;
　　30 /
　　PL/SQL procedure successfully completed.
　　Elapsed: 00:01:16.31
　　SQL> SET TIMING OFF;
　　列表 1 使用与您的出产情形不异的沙箱情形，简单斗劲启用列加密前后加载代表性数据集所破耗的时刻，以使您更好地体味列加密对出产系统机能的影响。
　　和所有的机能测试一样，我思疑对列进行加密所造成的机能损失踪会因系统而异，具体取决于通俗变量（CPU、平均负载等）。在列表 1 中，您注重到计较的机能损失踪为 36% (((56.14-76.31)/56.14)*100)，可是，使用我们在客户系统中收集的尝试证据，估量数据加载过程所破耗的时刻应该大约增添 11%，这与在出产中使用 TDE 获得结不美观完全一样。
　　在本例中，我着重于对具有索引的数据加载过程估量数据加密的机能损失踪。如不美观您的系统具有分歧类型的关头过程，如要求苛刻的报表生成周期，那么我建议您使用沙箱情形来斗劲数据加密前后该过程所破耗的时刻。本文后面的“确定潜在发芽打算更改”部门将谈判发芽和数据加密的出格注重事项。
　　措置停机和维护时刻
　　我的客户斗劲关心的另一个问题是，在加密约一百万行的表中的现有列数据时，需要对哪些出产应用轨范（如不美观有）进行需要的停用。我最初设法是，理论上不需要遏制任何应用轨范 — 事实下场，Oracle 文档明晰暗示了对现有列的数据进行加密素质上就是对折个表进行多行更新。如不美观没有更多地考虑这件事，我不会大白为什么新行无法并发插入到表中以及为什么现有行更新无法继续。当我咕哝着熟悉的 Oracle 口号“篡夺方不会阻止写入方，写入方也不会阻止篡夺方”时，我简直没有想到列加密会影响发芽。
　　可是，在长时刻从事 DBA 工作后，我才总结出，若要对出产系统进行最终的现实更改，需要对理论进行测试，以避免呈现意外问题，这一点很是主要。您瞧，当我在加密列时代，针对沙箱数据库对应用轨范自己进行了测试，从而发现了良多问题。最主要的是，我发现进行中的加密延迟了某些发芽的响应时刻，以至于应用轨范会碰着响应超时。这些超时又会造成毗连断开，然后导致后续的事务失踪败，进而会加倍麻烦 — 我将为您供给具体信息。
　　必需一提的是，测试之后，我体味到遏制应用轨范运行绝对不是没有理由的。但下矣闽问题是，出产应用轨范需要脱机多久？在打算每个周末进行的正常两小时的维护时刻之内能够对列进行加密吗？或者，需要更长的停机时刻？为了弄清这个问题，我只需测量在沙箱情形中对列进行加密所破耗的时刻，因为沙箱情形与出产情形具有不异的处事器硬件和数据集。我发现，列加密要破耗一个小时多一点的时刻才能完成。率直地说，因为我使用近似数据在标识表记标帜本电脑上模拟测试加密运行才破耗了不到 5 分钟的时刻，是以对于它破耗这么长时刻，我感应很是震动。可是当我们在出产数据库系统中对列进行加密时，最要紧的是要使用陈旧处事器硬件所发生的情形。
　　体味到在正常维护时刻内执行其他使命需要更多时刻，我抉择必需找到削减加密列破耗时刻的体例。我的第一个直觉就是删除包含方针列的两个索引。这样，Oracle 只需加密表自己中的列数据，之后我可以有用地重建索引，而没有日志记实狷。经由一些新的测试之后，我将加密列以及相关索引所需的时刻从 70 分钟（在加密时代放在索引）削减到仅 20 分钟（加密列后重建索引）。列表 2 是我用来得出结论的测试示例（从我们在列表 1 中遏制的位置继续）。此外，请注重，列表中的时刻来自用来编写本文的测试系统，而不是来自我的客户端使用的现实系统。

		自动登录	找回密码
密码			立即注册

[其他] Oracle认证：使用Oracle的TDE特性加密(1)