在Sybase Adaptive Server Enterprise中保护数据隐私

ehxz

安全漏洞
遍布于公司各处的数据库收集和存储着各种各样关键的个人隐私数据，如：社会保险号码，信用卡卡号，生日以及银行账户信息，同时相关医疗卫生和保险数据库存储着大量的病历信息。为了保护用户的隐私和杜绝数据失窃，人们已经采用了复杂而有效的安全措施和步骤来控制网络和数据库访问。
但是有一个方面有时会被忽视，那就是当公司丢失了计算机、存储设备或备份磁带、或者计算机被黑客侵入—— 个人数据将暴露无遗。
这种形式的数据暴露是屡见不鲜的，近来：
◆某研究机构报告其丢失了一台笔记本电脑，该电脑中存储着包括超过98，000份申请人的个人数据。

◆某医疗机构的两台计算机被窃导致185,000位病人的个人数据丢失。

◆某联邦承包商报告由于一台桌面计算机被窃，其35,000名股东将面临风险。
不幸的是，当这些窃贼得到了这些设备后，他们可以利用一些工具绕过数据库访问控制机制，从而直接读取磁盘物理块来恢复关键数据。
为了保护在介质（如磁盘和备份磁带）上的数据，当今最有效的方法是在这些数据写盘之前就对其进行加密。
进行磁盘加密工作
为了有效管理磁盘加密并且提供高级别的安全防护，需要解决三个关键问题，而这正是Sybase ASE 加密选项所能够解决的。
首先，整个加密系统必须独立于应用系统，并且不能改动应用程序。大多数数据库管理系统和一系列的应用软件捆绑运行。对于应用程序的修改将会增加系统的开销并且提高实施安全系统的复杂性。而且这也引发了一系列新的问题，例如如何确保应用系统和安全软件接口的有效性，同时不会产生新的安全漏洞。这就是为什么简单的“加密”和“解密”应用功能并不足以适合整个安全解决方案的原因之一。
不同于其它解决方案，Sybase ASE 加密选项并不需要修改程序。相反的是，它可以直接通过数据库的安全管理机制对数据进行加密，同时保持现有应用和数据不变。由于Sybase的这种数据加密机制，数据库表结构并未发生变动，因此查询和数据操作代码都无需改动。
其次，密钥必须被妥善保管。缺乏对密钥的保护是安全系统经常碰到的问题。密钥的安全性是最基本的。通常系统内部管理密钥比在网络上传输密钥能更有效地保护密钥。
为了避免外部密钥的缺陷，Sybase ASE加密选项在服务器内管理密钥。密钥以一种加密格式存储在数据库的sysencryptkeys 表中。例如，为了给AES加密算法产生一个名为ssn_key的密钥，可以使用命令：

create encryption key ssn_key for AES

当这个命令执行后，新的ssn_key密钥就可以使用了。
利用Sybase ASE加密选项，改变密钥只需简单的两个步骤：产生一个新的密钥，然后利用新密钥进行加密。例如：

create encryption key new_ssn_key for AES alter table employee modify ssn encrypt with new_ssn_key

第三，以授权为基础的访问机制必须建立起来。通常有许多方式可以控制对于加密数据的访问。最简单的方式是将密匙提供给用户和应用。然后应用在对数据进行访问的时候将密匙传送到解密点。然而这种做法有两个主要缺陷:
◆为了可以对密匙进行操作，应用需要进行修改。

◆密匙被暴露在数据库之外。

◆密匙在传送的过程中必须加以保护

◆密匙的发布将成为新的问题，因为必须保证新密匙可以安全地发布给用户和应用程序。改变密匙同样面临这个问题。

◆多个程序访问公共加密数据需要共享密匙。
Sybase ASE加密选项通过利用以授权为基础的访问机制有效地避免了以上的问题。用户和用户组可以仅仅通过授权即可访问加密数据，而不需要用户和应用传输密匙。没有被许可的用户无法看到数据。表署主（Table owners）通过GRANT 和 REVOKE命令就可以方便地管理许可控制。例如：为了给用户授权在customer表上的ssn列的解密许可角色 —— account_manager_role，表署主使用以下命令：

grant decrypt on employee(ssn) to account_manager_role

在这个例子中，只有拥有account_manager_role 角色的用户才能看到被解密的ssn列，而其他用户将会得到一个许可错误的报错信息。而在此过程中，应用无需修改。
保证安全性 —— 同时还有性能
Sybase ASE加密选项在列级别操作。 这可以很方便地加密个人隐私数据，如用户的社会安全号码等；而无需加密那些一般数据，例如居住地等。利用Sybase ASE加密选项提供的内置加密技术，数据库表署主可以利用ALTER TABLE命令的扩展方便地对现有表进行加密。例如：利用名为ssn_key的密钥对customer 表的ssn列进行加密，表署主可以利用以下命令：

alter table employee modify ssn encrypt with ssn_key

如果以后要取消加密，可以使用命令：

alter table employee modify ssn decrypt

表署主可以针对不同类型的数据采用不同的加密模式。因为我们将进行加密和解密的工作量降低到了最低程度，所以我们可以很容易地保证操作性能。在有些时候对同一段明文加密成同一段编码是非常有效的。例如：如果电话号码“555-123-4567”一直被加密为“tY6DLpUc1q”，那么数据库系统可以很方便地搜索加密过的“555-123-4567”。
这种技术对于在数据库中重复率很低的数据来说通常是安全的，比如：电话号码或社会保险号码，因为这些数据都是唯一存在的。然而，对于一些数据重复率较高的数据就不可以了。例如：假设我们有一个针对投票系统的加密系统，记录结果为“Yes” 或 “No”的选票。所有的“Yes”被加密成“0x4609c2fa”，所有的“No” 被加密成 “0xa123b4e1”，没有其它的保护措施。当然，这会让我们更容易地在这张表的vote列上进行join操作，但同时，这也意味着一个未经授权的人可以很方便地根据一种选票的纪录而推算出其余的结果。
对于这类问题的解决办法是采用伪随机数初始化向量技术，在数据被加密之前对数据值进行变更。利用ASE内置的加密机制，我们可以在密钥产生的时候进行声明。例如：产生一个名为vote_key的、带有随机数初始化向量的密钥，可以采用以下命令：

create encryption key vote_key for AES with init_vector random

Sybase加密功能使用一种简单、直接的脚本语法
以信用卡为例，我们假设用一张名为order的表来管理信用卡交易，包括：在credit card列中存储卡号（16个字节），在exp_data列中存储到期时间（4个字节）。我们希望保护信用卡号和相应的到期时间。表结构如下：
RDERS

Order_no	lname	fname	credit_card	exp_date	● ● ●
● ● ●	● ● ●	● ● ●	● ● ●	● ● ●	● ● ●

我们同时还有两组操作人员需要访问信用卡数据；他们是订单提取人员和账单管理员工，分别表示为order_taker_group 组和 billing_staff_group组。
为了保护这张表，我们首先为信用卡卡号和到期时间产生密钥。因为信用卡到期时间只限于几个日期并且这张表的数据量将会非常庞大，我们将利用随机数初始化向量的加密方式保护到期时间数据。假设加密选项已经安装并被初始化，产生密钥的命令如下：

create encryption key card_key for AES with init_vector null create encryption key exp_key for AES with init_vector random

接下来我们对数据列进行加密：

alter table orders modify credit_card encrypt with card_key, exp_date encrypt with exp_key

现在列已经被加密了。然后我们还要确保订单提取人员和账单管理员工可以看到这些加密数据的明文。

grant decrypt on orders(credit_card, exp_date) to order_taker_group, billing_staff_group

大功告成！无需应用修改，无需其它操作。
结论：Sybase ASE加密选项的优势
Sybase ASE加密选项在保护数据方面具有很多优势。首先，它不需要修改应用或表结构，这意味着在不影响现有应用实施计划的前提下可以快速实施数据加密。其次，可以通过内置的管理功能方便地管理和保护密钥。最后，通过使用简单、直接的脚本语法快捷地实施加密操作。