oracle資料庫加密
1、性能：在我們決定加密數據時，需要考慮的一個最大問題是，其性能影響如何？而對這個問題的回答只能是「視方案而定」。在我們的經驗中，透明加密執行起來很好，它對資料庫的性能影響一般從5%到8%不等。本地資料庫對象加密對性能的影響可達到15%到20%。所以，企業必須根據自己的配置狀況和性能要求考慮好此問題。
2、操作：如果你要加密介質，最好能夠保證在需要時能夠及時從此介質恢復。這就要求你經常測試磁帶。同樣道理，如果你使用密鑰輪換來滿足監管要求，就應當試這個過程的操作過程和方式，並測試你的廠商如何處理生產環境中的新密鑰和老密鑰。你最好按照計劃來進行，而不要在懷疑某個加密密鑰遭受破壞後才去測試。
3、復雜程度：加密系統都很復雜。你必須考慮加密引擎在哪裡，它如何加密數據及加密哪些數據，哪些數據不加密，怎樣提供密鑰等等。作為一位資料庫管理員，你需要認識到這種復雜程度並保證自己完全理解加密系統如何工作，特別是在你要證實加密能夠正確地滿足合規要求時，這尤其重要。加密的復雜性不僅體現在部署方面，還體現在實施階段。有人認為加密只不過是一個簡單的數學公式問題，甚至還有人說，「咱能自己搞定！」。此言差矣。許多很有才的安全專家都在建設自己的加密系統時栽了跟頭。不要去建立自己的安全加密系統。否則，輕則造成不安全，重則會丟失所有數據。所以，你應當採用一種經過檢查的可信的加密產品。
4、密鑰管理：你需要一個密鑰管理系統來保護密鑰。管理員不能將密鑰存儲到資料庫中，也不能將密鑰存放到磁碟上。企業應當將密鑰管理規劃到預算和操作計劃中。
㈡ 關於oracle資料庫加密的函數
在程序裡面把密碼加密之後保存到資料庫就好了。/摳鼻
㈢ 如何在oracle 10g r2中實現透明數據加密
設置加密密鑰：
Oracle 透明數據加密提供了實施加密所必需的關鍵管理基礎架構。 加密的工作原理是將明文數據以及秘密(稱作密鑰)傳遞到加密程序中。 加密程序使用提供的密鑰對明文數據進行加密，然後返回加密數據。 以往，創建和維護密鑰的任務由應用程序完成。 Oracle 透明數據加密通過為整個資料庫自動生成一個萬能密鑰解決了此問題。 在啟動 Oracle 資料庫時，管理員必須使用不同於系統口令或 DBA 口令的口令打開一個 Oracle Wallet 對象。 然後，管理員對資料庫萬能密鑰進行初始化。 萬能密鑰是自動生成的。
性能：
由於索引數據未被加密，因此加密通常會影響現有的應用程序索引。 Oracle 透明數據加密對與給定應用程序表關聯的索引值進行加密。 這意味著應用程序中的相等搜索對性能的影響很小，甚至沒有任何影響。 例如，假設應用程序 card_id存在一個索引，並且此應用程序執行以下語句：
sql> Select cash from credit_card where card_id = '1025023590';
Oracle 資料庫將使用現有的應用程序索引，盡管 card_id信息已經在資料庫中加密。
准備用於加密的資料庫：
在本部分內容中，您將更新 sqlnet.ora、創建一個加密錢夾 (ewallet.p12)、打開此錢夾並為 TDE創建萬能密鑰。執行以下操作：
1. 您需要更新 sqlnet.ora 文件以包含一個 ENCRYPTED_WALLET_LOCATION 條目。打開一個終端窗口，然後輸入以下命令：
cd $ORACLE_HOME/network/admin
gedit sqlnet.ora
將以下條目添加到文件末尾：
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/admin/test97/wallet/)))
如果不加這一項的話，則會提示下面錯誤：
SQL> alter system set key identified by "hurray"
2 ;
alter system set key identified by "hurray"
*
ERROR at line 1:
ORA-28368: cannot auto-create wallet
/opt/oracle/admin/test97/wallet/ 目錄是用來存放生成的錢夾的。
可以為加密錢夾選擇任何目錄，但路徑不應指向在資料庫安裝過程中創建的標准模糊錢夾(cwallet.sso)。
2. 接下來，您需要打開錢夾並創建萬能加密密鑰。從終端窗口中，輸入以下命令：
connect / as sysdbaalter system set key identified by "welcome1";
此命令的作用為：
l 如果指定的目錄中不存在加密錢夾，則將創建加密錢夾 (ewallet.p12)、打開此錢夾並創建/重新創建 TDE 的萬能密鑰。
l 如果指定目錄中存在加密錢夾，則將打開此錢夾並創建/重新創建 TDE 的萬能密鑰。
之後，就可以測試數據了。
下面是實驗記錄：
alter system set key identified by "welcome1";
SQL> conn dodd/dodd123
create table test (id number,credit_card_number varchar2(16) ENCRYPT NO SALT);
SQL> insert into test values(1,'1231243242');
1 row created.
SQL> insert into test values(2,'33245235');
SQL> commit;
Commit complete.
SQL> select * from test;
ID CREDIT_CARD_NUMB
---------- ----------------
1 1231243242
2 33245235
可見，數據查看是明文，因為這個時候，加密錢夾已經打開，數據可以解密。
這時，停止資料庫，再打開：
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> SQL> startup
ORACLE instance started.
Total System Global Area 524288000 bytes
Fixed Size 1979968 bytes
Variable Size 138414528 bytes
Database Buffers 377487360 bytes
Redo Buffers 6406144 bytes
Database mounted.
Database opened.
SQL> select * from dodd.test;
select * from dodd.test
*
ERROR at line 1:
ORA-28365: wallet is not open
SQL> select id from dodd.test;
ID
----------
1
2
可以看到，因為資料庫重啟後，加密錢夾處於關閉狀態，這時只要查詢到加密的列，會提示加密錢夾沒有打開。
如果用戶想打開錢夾，必須具有alter system許可權。
下面打開wallet：
SQL> conn / as sysdba
Connected.
SQL> alter system set wallet open identified by "welcome1";
System altered.
SQL> conn dodd/dodd123
Connected.
SQL> select * from test;
ID CREDIT_CARD_NUMB
---------- ----------------
1 1231243242
2 33245235
可以看到，加密錢夾打開後，數據可以被解密。
還有一條：sys用戶的表不能被加密。
可見：Oracle TDE是在數據層面上對表裡的數據加密，而且不會影響資料庫現有的許可權控制策略。
salt實際上就是在加密過程中引入一個隨機性。簡單的說，就是一般來說，同樣的明文產生同樣的密文，這樣就導致容易被解密者通過分析詞頻之類的方式(加解密我不太懂)來通過密文破解明文，如果指定salt，那麼即使同樣的明文加密後的密文也是不一樣的。
no salt的話，自然就是相同的明文會產生相同的密文了。對於索引來說，要求no salt也就可以理解了
丟失ewallet加密錢夾的話，是不能再解密數據的。
Oracle 10gR2的 TDE 特性，對於防止機密信息的泄漏能起到事半功倍的作用!
㈣ 如何應對被公開的Oracle口令加密演算法
由於Oracle資料庫被廣泛應用，其口令加密演算法也是備受關注。最早在1993年comp．databases．oracle．server新聞組中有人披露了加密演算法的大部分細節。十年後，一本名為《Special Ops Host and Network Security for Microsoft， Unix and Oracle》的書中補全了演算法最重要的一個環節——DES演算法的KEY。至此，口令加密演算法已無秘密可言。接踵而來的是互聯網上出現多個了Oracle口令破解工具。Oracle在2007年推出的最新版本11g中，使用了新的更安全的加密演算法，但是新演算法的細節很快又在互聯網上被公開。為提供兼容，11g版本保留了11g以前版本使用的加密口令，利用這一漏洞仍然可以對11g版本的加密口令進行破解。
到底怎樣才能保證資料庫口令的安全呢？本文首先介紹Oracle資料庫各版本口令加密演算法的內容，然後針對演算法重點介紹加強資料庫安全性的應對措施。
口令加密演算法
從Oracle7到Oracle 10gR2，使用DES演算法對口令進行加密。對演算法進行分析，可以得出如下結論：口令不區分大小寫，任意大小寫組合均可登錄；由於只使用固定KEY，只要用戶名和口令相同，在任一DB中存放的加密口令都相同；由於採用了用戶名和口令串接的方式，所以用戶aaa、口令bbbccc的加密值與用戶aaabbb、口令ccc完全相同。
Oracle 11g版本的加密口令存放在SYS．USER$表中的SPARE4列中，而PASSWORD列中仍保留以前版本加密口令。由於客戶端計算加密口令需要用到SALT，在建立連接時，伺服器端將SALT明文傳送給客戶端程序。Oracle 11g中新的口令加密演算法中區分大小寫；由於加入了隨機數SALT，兩個不同用戶的口令即便完全相同，計算得到的SHA1的散列值也不同；不同DB中相同用戶相同口令，SHA1散列值也可能不同。
目前，大多數破解工具的工作方式是得到加密口令後，對每一個可能的口令進行加密計算，比較計算結果而確定是否正確。由此，抵禦口令破解可以從三個方面著手：防止加密口令外泄；在加密口令落入黑客手中後，口令也是不可破解的，或盡量增加破解的時間；即便是口令被破解，也是無用的，不能存取資料庫。
防止加密口令泄露
1．應用「最少許可權」原則，盡量限制可存取加密口令用戶的人數
在資料庫中檢查具有存取SYS.USER$或DBA_USERS許可權的用戶，並從不需要的用戶中收回許可權。但是操作並不簡單，這也是資料庫管理工作的特點。每一廠商的軟體中都實現了SQL標准之外的擴充，並且每一版本都有差異。限於篇幅，不可能對所有本文中建議的措施進行詳細的解釋說明，僅以此處檢查許可權為例展示DBA工作的復雜性。本文中如未說明，則默認版本為11g。應用於11g以前版本時，請讀者確認是否需要修改。
檢查許可權主要的工具是數據字典視圖（也可以直接存取SYS用戶的基表，但基表的定義沒有公布，官方不提供技術支持）。視圖DBA_TAB_PRIVS存放了資料庫中數據對象上的授權信息。假定用戶A1和A2可以存取SYS．USER$表，檢查在SYS用戶USER$上有存取許可權的用戶，可執行如下語句：
SELECT GRANTEE FROM DBA_TAB_PRIVS WHERE TABLE_NAME=『USER$』；
我們已經知道用戶A1和A2，都可以存取SYS.USER$表，但為什麼在上面查詢結果中沒有出現呢？這是因為在Oracle的許可權管理中，對一個表的存取許可權還可以通過系統許可權或角色賦予，而DBA_TAB_PRIVS中僅列出了直接的對象許可權的授予信息。對於SYS．USER$表而言，系統許可權SELECT ANY DICTIONARY和角色DBA都包含了這一表的存取許可權。所以完整列出所有可存取這一表的用戶應增加下面兩條查詢語句的結果：
SELECT GRANTEE FROM DBA_SYS_PRIVS WHERE PRIVILEGE＝『SELECT ANY DICTIONARY』；
SELECT GRANTEE FROM DBA_ROLE_PRIVS WHERE GRANTED_ROLE＝『DBA』；
通過上面的查詢語句，還是會遺漏某些用戶。如果把DBA角色授權給另一角色Admin，然後又將Admin角色授權給另一用戶NEWU，則此用戶可存取SYS.USER$表，但在上述三個查詢中並沒有直接列出NEWU的名字（角色Admin會出現在第三個查詢語句的結果中）。
顯然，Oracle的授權構成了一棵樹，完整的信息需要一段PL/SQL程序來完成。（對於11g以前版本，還需要檢查對DBA_USERS視圖有存取許可權的用戶和角色。SELECT_CATALOG_ROLE角色如被授權，則可以存取所有數據字典視圖，但不能存取SYS的基表。）
2．設定對加密口令存取的審計
如果當前系統中只有SYSDBA可以存取USER$，則一個變通辦法是審計SYSDBA的所有操作，其中也包括對USER$的存取。設置初始化參數audit_sys_operations ＝TRUE，重新啟動資料庫後激活對SYSDBA操作的審計。
審計文件的存放位置為：
11g版本中為：$ORACLE_BASE/admin/SID/ amp／ *．aud
11g以前版本為： $ORACLE_HOME/rdbms/audit/ *．aud。
嚴格限制和監視SYSDBA用戶活動的最好辦法是使用Oracle Database Vault組件。
3．在操作系統級限制對資料庫數據文件的存取
SYSDBA用戶的加密口令存放在$ORACLE_HOME/dbs下的口令文件orapw〈SID〉中。SYS．USER$表同樣需要在數據文件中存放，多數為SYSTEM表空間的第一個數據文件中。此外，EXPORT文件、REDOLOG文件以及TRACE文件中都可能出現加密口令。需要嚴格限制上述文件的存取許可權。
4．防止網路竊聽
在建立連接時，客戶端需要向伺服器端傳送用戶名和口令，並且伺服器端與客戶端需要相互發送這次會話使用的SESSION KEY。Oracle採用Diffie-Hellman KEY交換演算法和自己開發的O3LOGON協議完成上述任務。演算法的細節同樣已在互聯網上被公開。建立連接時上述信息如果被截獲，同樣可以被用來破解口令。更為嚴重的是，如果黑客事先已經獲得加密口令，結合SESSION KEY的信息，則不需要任何破解，執行簡單還原運算就可算出口令明文。
另外，設計SID時不要使用如ORCL、TEST、PROD等常用名字，設定PORT號為遠遠大於1521的數，都可以增加黑客SID掃描的難度和時間。
5． 刪除舊版的加密口令
存放在Oracle 11g資料庫中的以前版本的加密口令是口令破解工具的一個突破口。在沒有兼容性限制的系統中，可以考慮從系統中刪除舊版口令，從而增加破解難度。
具體操作如下：
在SQLNET.ORA中增加一行：SQLNET.ALLOWED_LOGON_VERSION=11（Oracle手冊中格式介紹有錯誤，不能加括弧：…＝（11）），指定最低版本。
以SYSDBA登錄後，執行以下語句，刪除舊版口令。
update sys.user$ set password＝NULL；
delete from user_history$；
commit；
設置修改後，基於OCI的工具如SQLPLUS、10gR1和10gR2版本都可以正常登錄，而JDBC type-4 則只有11g版本才允許登錄。
提高口令強度
1．禁止使用預設口令，禁止與用戶名同名的口令，禁止字典詞彙的口令
Oracle 11g中提供一個視圖DBA_USERS_WITH_DEFPWD，可以方便地查出系統中使用預設口令的所有用戶，不足的是還有不少遺漏。讀者可以在互聯網找到預設口令的列表，雖然是非官方的，但是比DBA_USERS_WITH_DEFPWD使用的官方的列表更全。破解工具附帶的詞彙表有的包括了大型英文詞典中全部詞彙，並支持詞彙與「123」之類的常用後綴進行組合。需要注意的是，有的詞彙表中已經出現了「zhongguo」這樣的字元串，所以漢語拼音組成的口令也是不安全的。檢查系統中是否存在弱口令的最常用方法就是使用前述口令破解工具進行攻擊。
2．規定口令最小字元集和口令最短長度
口令字元集最小應包括字母、數字和特殊符號，口令長度最短應不少於8位，對於安全性要求高的系統，最短長度應為12位以上。同樣，問題的關鍵在於DBA指定初始口令以及用戶修改口令時保證不違反上述這些規定。每一用戶都對應一個Profile，如在Profile中指定口令驗證函數，則每當創建或修改口令時，會自動檢查是否滿足驗證程序中所設定的條件，如果不滿足，則口令修改失敗。對口令明文進行檢查，顯然要比對加密口令破解效率高。此外，口令創建之時進行檢查可以及時封殺弱口令，不給黑客留下破解的窗口。
指定口令驗證函數的語句為：
ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION 口令驗證函數名；
上例中，為「DEFAULT」 Profile指定了驗證函數。對用戶進行分類後，應當為每一類用戶分別創建自己的Profile，而不是全部使用DEFAULT。關閉口令驗證函數的語句為：
ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION NULL；
在$ORACLE_HOME/rdbms/admin/下，腳本文件UTLPWDMG.SQL提供了示例的口令驗證函數，執行這一腳本，將創建一名為VERIFY_FUNCTION的函數( Oracle 11g中，增加新函數verify_function_11G )。這一函數可以對口令長度是否同時出現了字母數字元號進行檢查，檢查是否與用戶名同名，也檢查口令是否是幾個最常用的詞彙，如welcome、database1、account1等。最後，口令修改時檢查新舊口令是否過於相似。讀者實際使用時應該根據系統需要對這一函數進行必要的修改和擴充。
3．使用易記憶的隨機口令限定口令長度後，如果口令沒有規律很難記憶，則用戶會採用他們自己的方式記住口令，大大增加了遭受社會工程攻擊的可能性。DBA需要幫助用戶設計一個容易記憶而又不易破解的口令。一個簡單易行的方法是找用戶非常熟悉的一個句子，如One world One dream，然後將每一個空格替換為數字或符號：One3world2One1dream#。
定期更換口令
抵禦口令破解要從多方面著手
資料庫中存在多種許可權用戶，各種授權用戶構成一棵樹
應對口令泄露或被破解的措施是強制定期更換口令，設定口令重復使用限制，規定封鎖口令的錯誤次數上限及封鎖時間。即便是加密口令落入黑客手中，在被破解之前或入侵之前，修改了口令，則口令破解變得毫無意義。為了方便記憶，一般用戶有重新使用之前過期口令的傾向，如果對重用不加控制，則定期更換口令將失去意義。上述對口令的管理仍然是通過Profile完成：
ALTER PROFILE DEFAULT LIMIT
PASSWORD_LIFE_TIME 30
PASSWORD_GRACE_TIME 7
PASSWORD_REUSE_TIME 365
PASSWORD_REUSE_MAX 0
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_LOCK_TIME UNLIMITED
PASSWORD_VERIFY_FUNCTION my_verify_function;
上面語句制定的口令管理政策為：口令的有效期為30天，隨後有7天的寬限期，寬限期後口令「過期」，必須更改口令後才能登錄。只有經過365天後才能重新使用以前的口令。在連續10次輸入口令錯誤後，賬號被封鎖，設定不自動解鎖，必須由DBA手動解除封鎖。口令驗證函數為my_verify_function。
Oracle 11g以前版本，預設設置中沒有設定口令的有效期，而在Oracle 11g中預設設置有效期為180天。程序中直接寫入口令的應用在升級到11g時一定要注意有效期問題，避免半年後應用突然無法自動運行。另外，口令的有效期對SYS用戶不起作用，DBA一定要主動定期更換口令。
另外一個措施是對登錄資料庫伺服器的主機進行限定，如指定網段或指定IP地址。進一步限定客戶端允許執行的程序，如對非本地登錄禁止使用SQLPLUS，只允許執行某特定應用。
認真實施本文中給出的措施後，可以很有效地防止口令被破解。然而我們的目的是提高資料庫系統的安全性，而不僅僅是保證口令不被破解。資料庫系統安全的任何一個環節出現問題，都會導致前功盡棄。黑客的目的是入侵系統盜竊數據，是不會按常理出牌的，會嘗試各種手段方式，如社會工程、安全漏洞、物理入侵等等，而不會執著地在口令破解上與我們較勁。這一點需要我們經常提醒自己，從而切實保證資料庫系統安全。
TechTarget中國原創內容
㈤ oracle資料庫透明加密問題
同樣求解
㈥ oracle 欄位加密
這是程序加密的，具體的你要看代碼採用的是什麼加密演算法，常見的是MD5加密
㈦ 如何把oracle資料庫中的密碼這一項的欄位都改成MD5加密的
UPDATE table SET 密碼=MD5(密碼);
不知道oracle中有沒有，mysql中是存在的。
㈧ oracle，加密，哈希
一般表裡直接存的就是hash值的密碼
然後前台客戶輸入明文密碼，然後提交，
系統自動把明文轉成hash值的16進制密碼去跟用戶信息表匹配
而即使被黑客入侵，得到的也只是hash值，得不到明文
㈨ 如何將密碼加密後存入oracle資料庫
加密的字元串一般是在
程序當中生產的比如現在流行的16位
md5
加密碼。一般都是在程序當中對用戶輸入的
真實密碼。進行一個
MD5加密
，會生產一個加密碼。然後按需要截取其中16位。在把這16位MD5加密碼
字元串
存取在資料庫當中。在用戶登入的時候。用戶會輸入真的密碼在進行加密截取。然後和資料庫當中的進行比較。如果成功則true反之為fasle
㈩ oracle資料庫有自帶的加密解密功能嗎
沒有