當今大多數 Web 應用程式都需要至少採用某種基本的安全性原則。例如,提供用口令保護的內容的網站、僅具有管理員後端的網站、網誌和個人雜誌、電子商務網站、企業內連網,等等。
構建這些類型的 Web 應用程式最常用的設計方法是將安全性原則整合到 Web 應用程式的商務邏輯中,即由應用程式決定某個使用者是否有權訪問資料庫中的某個資料。在這種情形下,資料庫的角色僅為儲存資料和依請求提供資料。換句話說,如果 Web 應用程式命令資料庫提供特定資訊,則資料庫會直接執行該命令而不檢查使用者的許可權。
從 Web 應用程式控制資料訪問會怎麼樣?大多數情況下沒有問題;這是個不錯的解決方案,尤其是在涉及的資料為非任務關鍵或絕密的時候。許多書和線上資源中都用到了該方法。實際上,有本很受歡迎的 PHP/MySQL 書明確反對每個應用程式建立一個以上的資料庫使用者帳戶,這是因為“額外的使用者或複雜的許可權會因某個操作在繼續前要檢查更多的資訊而降低 MySQL 的執行速度”。確實如此;但是,在放棄將安全性整合到資料庫邏輯中的想法前可能要考慮幾件事情。我們來看以下樣本。
假設建立一個內容管理系統 (CMS)。其中使用資料庫來儲存網站上發布的內容。大部分資料是公開的,允許匿名 Web 使用者讀取;但只允許編輯更改資料。使用單一資料庫帳戶訪問和修改資料庫中的記錄,並通過用口令保護僅管理員可以訪問的頁面的存取權限用 PHP 代碼控制安全性。
GRANT CONNECT to cms_user;
GRANT CONNECT to cms_editor;
現在,如果嘗試以 CMS_USER 或 CMS_EDITOR 使用者登入並試圖從 WEB_CONTENT 表讀取資料 (select * from hr.web_content;),將遇到以下錯誤:
ORA-00942:table or view does not exist
為了訪問資料或僅是看到表,需要授予 CMS_USER 和 CMS_EDITOR 帳戶對 WEB_CONTENT 表的唯讀許可權:
GRANT SELECT on hr.web_content to cms_user;
GRANT SELECT on hr.web_content to cms_editor;
以上代碼使這兩個帳戶可以對 WEB_CONTENT 表執行 SELECT 語句。如果嘗試執行其他語句,則會遇到錯誤。例如,插入一行:
INSERT INTO hr.web_content (page_id,page_content) VALUES (1,'hello world');
將產生錯誤訊息
GRANT SELECT ON web_content TO reader;
GRANT INSERT,UPDATE,DELETE ON web_content TO writer;
賦予使用者角色:
GRANT reader TO cms_user;
GRANT reader TO cms_editor; (they need to read too)
GRANT writer TO cms_editor;
請注意,如果更改 READER 角色的定義,則這些更改會影響所有具有該角色的使用者帳戶。如果是直接將許可權授予使用者的,則必須逐個更新每個使用者帳戶。
完成上述步驟後,可以配置 PHP 應用程式,使之對由匿名 Web 使用者請求的所有資料庫連接均使用 CMS_USER 帳戶,對由受口令保護的管理頁面引發的串連使用 CMS_EDITOR 帳戶。現在,即使公用 Web 表單受到攻擊,該攻擊對資料庫的影響將微乎其微,這是因為 CMS_USER 帳戶僅具有唯讀許可權。
結論
在本文中,我們只是簡單介紹了 Oracle 資料訪問安全性的一些最基本的特性。此外,Oracle 還有許多其他特性,可把您的 Web 應用程式的安全性提高到一個新的等級 — 包括虛擬專用資料庫 (VPD) 和標籤安全性。