安全漏洞
遍布於公司各處的數據庫收集和存儲著各種各樣關鍵的個人隱私數據，如：社會保險號碼，信用卡卡號，生日以及銀行賬戶信息，同時相關醫療衛生和保險數據庫存儲著大量的病歷信息。為了保護用戶的隱私和杜絕數據失竊，人們已經采用了復雜而有效的安全措施和步驟來控制網絡和數據庫訪問。
但是有一個方面有時會被忽視，那就是當公司丟失了計算機、存儲設備或備份磁帶、或者計算機被黑客侵入—— 個人數據將暴露無遺。
這種形式的數據暴露是屢見不鮮的，近來：
◆某研究機構報告其丟失了一台筆記本電腦，該電腦中存儲著包括超過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加密選項在保護數據方面具有很多優勢。首先，它不需要修改應用或表結構，這意味著在不影響現有應用實施計劃的前提下可以快速實施數據加密。其次，可以通過內置的管理功能方便地管理和保護密鑰。最後，通過使用簡單、直接的腳本語法快捷地實施加密操作。
