半年前在對某單位的生產系統實施風險評估與安全加固項目中，在對oracle安全加固時發生一次嚴重的事故，致使全省的打表業務全部癱瘓，現記錄下來，希望對做信息安全的同仁敲醒警鐘。
在完成對被測系統的物理環境、網絡安全架構、網絡安全設備、安全系統、操作系統、數據庫、中間件、網絡-主機-數據庫日誌分析、應用系統後臺、數據備份與恢復、桌面終端、***測試、管理制度的安全評估檢查之後，當然我這裏就不說資產、威脅、脆弱性這評估三要素的問題了，直奔主題。接下來我們就開始針對系統存在的安全風險準備安全加固方案。並召開風險評估小結會和安全加固會，會上對存在的安全風險進行了分析，並講解了安全加固的策略細節以及注意事項。其中講到了oracle存在一個安全風險是未撤銷PUBLIC角色對UTL_FILE、utl_http、UTL_TCP、utl_smtp的執行權限。判定的理由是如果控制數據庫包UTL_FILE讀寫目錄的參數被設爲“*”（不包括引號），UTL_FILE包就可以被讀寫到機器上Oracle安裝用戶（通常是用戶（ORACLE）訪問的任何目錄。一個有“ALTERSESSION”權限的用戶就可能會複製庫緩存（librarycathe）到一個跟蹤文件，然後通過UTL_FILE讀取文件的任何內容。如果添加任何用戶或修改密碼，那麼清晰的文本密碼都仍然會被看到（只要它不被從緩存中清除）。而且Oracle默認授權public角色能對這些包有執行權限，但是應用開發人員很少使用UTL_FILE來進行導入導出數據。
具體的加固命令是
SQL>connect / as sysdba;
Connected.
SQL>revoke execute on utl_file from public;
Revoke succeeded.
當時會上開發廠商提出應用系統可能在用UTL_FILE，但是不確定。所以我們在會上就把暫停對撤銷權限的這部分的加固。這裏我們也犯了一個錯誤，我們以爲他們內部會溝通這個問題，而且對方oracle運維人員是個OCM，應該瞭解應用，就沒給在外地的數據庫管理員說明會中具體細節。又因爲他們數據庫管理員在外面培訓，沒法配合我們現場加固，領導決定就讓運維人員遠程加固。第二天運維人員自己直接加固了，我們沒參與數據庫加固的工作。然後就是全省的該應用系統的打表業務全部癱瘓，營業廳打到業務部門諮詢情況的電話快打爆了，經過測試將問題聚焦到回收public的執行包權限的問題上，速度把撤銷權限的操作重新賦權限，數據庫恢復正常。
具體的恢復命令是：
SQL>connect / as sysdba;
Connected.
SQL>grant execute on utl_file to public;
Grant succeeded.
故障原因就是當初程序開發時使用了這個還不常用的UTL_FILE包來進行導入導出數據，public角色的權限回收後，相應的應用用戶喪失了導出數據的權限，最終導致打表業務癱瘓，問題就是這樣。
在這個事件中我們實施方的責任是沒把會議結果和數據庫管理員做好溝通，評估方的責任就是數據庫管理員加固會議不在現場，開完會議內部不溝通，數據庫管理員審覈我們的腳本沒發現問題，數據庫管理員遠程加固沒和我們溝通。
透過這個事件我們吸取到的教訓是：
第一：評估的啓動會、小結會這種帶有重要意義的會議最好全員參加，尤其是開發應用人員和數據庫運維人員。
第二：做安全加固的配置一定要經過開發人員、運維人員、評估人員多方面組成的評審小組的評審，不確定的一概待定，並且保持消息共享，做好溝通工作。
第三：做信息安全一定要深入瞭解業務應用，通性配置加固可以減少顧慮，但是一旦貼近應用，譬如說部署了RAC的AIX小機的exec、login、shell等服務是否要禁用的問題，一定要謹慎小心。
第四:做信息安全一定要有業務至上的心，可以深度檢查，但是加固一定要求穩。做加固工作一定要剋制技術人追求極限的心，並非加固的項數越多越好。