程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> Oracle數據庫 >> Oracle數據庫基礎 >> Oracle數據安全面面觀(2)

Oracle數據安全面面觀(2)

編輯:Oracle數據庫基礎

(二)來自內部的另外一個隱患--用戶管理以及密碼問題

    在這裡,其實作為一個差不多點的數據庫管理員都很清楚,Oracle數據庫本身就使用了很多種手段來加強數據庫的安全性,經常見到的就有密碼,角色,權限等等。那麼我們就從最簡單的DBSNMP說起:

    Oralce數據庫如果采用典型安裝後,自動創建了一個叫做DBSNMP的用戶,該用戶負責運行Oracle系統的智能代理(Intelligent Agent),該用戶的缺省密碼也是“DBSNMP”。如果忘記修改該用戶的口令,任何人都可以通過該用戶存取數據庫系統。現在我們來看一下該用戶具有哪些權限和角色,然後來分析一下該用戶對數據庫系統可能造成的損失。 

    啟動SQL/PLUS程序,使用該用戶登錄進入:

SQL> select * from session_privs; 
CREATE SESSION 
ALTER SESSION 
UNLIMITED TABLESPACE 
CREATE TABLE 
CREATE CLUSTER 
CREATE SYNONYM 
CREATE PUBLIC SYNONYM 
CREATE VIEW 
CREATE SEQUENCE 
CREATE DATABASE LINK 
CREATE PROCEDURE 
CREATE TRIGGER 
ANALYZE ANY 
CREATE TYPE 
CREATE OperaTOR 
CREATE INDEXTYPE

    可以看到該用戶不是SYS或SYSTEM管理用戶,然而,它卻具有兩個系統級權限:UNLIMITED TABLESPACE和CREATE PUBLIC SYNONYM。

    看到這兩個權限你應該馬上想到,這些都是安全隱患,尤其是UNLIMITED TABLESPACE,它是破壞數據庫系統的攻擊點之一。如果這時候你還依然認為,即使有人利用這個沒有修改的口令登錄進數據庫也造成不了什麼損失的話,我就不得不提醒你:該用戶具有UNLIMITED TABLESPACE的系統權限,它可以寫一個小的腳本,然後惡意將系統用垃圾數據填滿,這樣數據庫系統也就無法運行,並將直接導致最終的癱瘓。目前很多數據庫系統都要求7X24的工作,如果出現了系統用垃圾數據填滿的情況,那麼,等數據庫系統恢復時,恐怕不可挽回的損失已經造成了。

     可是除了DBSNMP還有很多其他的用戶,怎麼辦呢?讓我們先看一下目前普遍存在於Oracle數據庫中的用戶管理問題:

    (1)權限過大:對Oracle數據庫編程和浏覽的一般用戶常常具有DBA (數據庫管理員權限),能對數據庫系統做任何修改或刪除。

    (2)安全性差:很多Oracle用戶缺省存儲位置都在系統表空間,這樣不僅影響系統的正常工作,而且不同用戶的數據信息互相影響、透明,保密性差。隨著數據的不斷加入,有可能使整個數據庫系統崩潰。

    (3)密碼有規律:在Oracle調試初期形成的用戶名和密碼一致的不良習慣保留到現在;系統用戶SYS和SYSTEM的密碼也眾所皆知。

    知道了這些普遍的“毛病”,我們怎麼做呢?下面是我的一些建議:

(1)Oracle DBA (數據庫管理員)的規范

    ·SUN Solaris操作系統下ORACLE用戶密碼應嚴格保密,絕不該把密碼設成Oracle;並指定專門的數據庫管理員定期修改。

    ·Oracle初始化建立的SYS和SYSTEM系統管理員用戶密碼應由原來MANAGER改成別的不易被記憶的字符串。

    ·Oracle WEB SERVER的管理端口具備DBA浏覽數據庫的能力,因此其管理者ADMIN的密碼也應保密,不該把密碼設成MANAGER;並指定專門的數據庫管理員定期修改。

    ·ORACLE DBA最好在SUN SPARC服務器控制台上用窗口式界面實現管理。前提是ORACLE用戶啟動服務器,然後在窗口式命令行下輸入SVRMGRM,即啟動了Oracle SERVER MANAGER菜單式管理;用SYSDBA身份登錄後,就可做數據庫系統維護工作了

(2)SQL*PLUS編程用戶的規范

    ·存儲結構的規范

    考慮到用SQL*PLUS編程可實現各行各業、各公司、各部門多種多樣的應用需求,我們的SQL*PLUS編程用戶也應該朝這個方向規范:不同種類的應用必須有不同的用戶;不同種類的應用必須有不同的存儲位置,包括物理文件、缺省表空間、臨時表空間的創建和規劃:當准備編寫某一較大規模(從Oracle數據量和面向用戶量考慮)應用程序時,首先應該創建一個邏輯的存儲位置-表空間,同時定義物理文件的存放路徑和所占硬盤的大小。

    ①、物理文件缺省的存放路徑在/oracle_home/dbs下,在命令行下用UNIX指令df -k 可查看硬盤資源分區的使用情況。如果Oracle_home使用率達90‰以上,而且有一個或多個較為空閒的硬盤資源分區可以利用,我們最好把物理文件缺省的存放路徑改到較為空閒的硬盤資源分區路徑下。在此路徑下我們可以這樣規劃資源物理文件的存儲:

xxx表空間
xxx行業/ xxx公司/ xxx 部門/ xxx 服務.dbf

DEMO表空間
default_datafile_home1/col /elec/sys4/demo1.dbf 
default_datafile_home1/col /elec/sys4/demo2.dbf

公司系統四部摹擬演示系統物理文件

HUMAN表空間
default_datafile_home1/col/elec/human/human.dbf

公司人事部人事管理系統物理文件

BOOK表空間
default_datafile_home1/col/elec/book/book.dbf

公司資料室圖書管理系統物理文件

QUESTION表空間
default_datafile_home1/col/elec/clIEnt/question.dbf

公司客戶服務部問題庫系統物理文件

PC表空間
default_datafile_home1/col/chaoxun/clIEnt/pc.dbf

公司PC機售後服務系統物理文件

……表空間
default_datafile_home2/……………………………

等等

    說明:其中default_datafile_home1指Oracle_home/dbs;default_datafile_home2指較為空閒的硬盤資源分區路徑。

    ②、物理文件的大小根據應用系統的數據量、數據對象、程序包的多少來定。一般用於摹擬演示的小系統,表空間初始的物理文件為2M即能滿足要求,如果信息量滿,還可以增加物理文件,擴充表空間(每次擴充大小也可暫定為2M);一般實際運行的應用系統可適當增加表空間初始的物理文件大小,但也不要一次分配太大(因為不易回收空間,卻易擴充空間),這也需要根據具體情況具體分析:信息量大、需長時間保存的應用在條件允許情況下,表空間可以大到幾百M甚至上G;信息量小、短期經常刷新的應用,表空間可以控制在2M以下。

    ③、表空間的名稱應該采用同系統應用相似的英文字符或字符縮寫,表空間所對應的一個或多個物理文件名也應有相關性。不同用戶所處的缺省表空間不同,存儲的信息就不能互相訪問。這比把所有用戶信息都儲存在系統表空間,安全性大大提高了。如果用Oracle WEB SERVER管理端口創建的用戶,其缺省和臨時表空間一定是系統表空間,DBA切記要改變用戶的缺省表空間。臨時表空間存放臨時數據段,處理一些排序、合並等中間操作,根據實際應用的需求可以把它們放在專門創建的表空間裡;如果系統表空間大,也可以把它們放在系統表空間。用戶創建的數據索引最好和數據文件分開存放在不同表空間,以減少數據爭用和提高響應速度。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved