[資安觀念] 意外"總是"會發生

前幾天跟一位多年不見的朋友見面，在談話中他提到了他在年初所遇到的一件慘事，那就是他們線上服務的網路儲存設備的 (Linux-based) 系統整個毀損，甚至造成了部分重要檔案的損失。早在10多年前 .COM 熱潮來襲的時候，那時候因為伺服器等級的硬體設備價格高昂，再加上日誌型的檔案系統還不普遍，所以系統損毀時有所聞。但是以目前硬體設備的價格，硬體式的 RAID 控制卡已經是伺服器的基本配備。在 RAID 的架構下，一般至少會採用可以容忍一顆以上硬碟損毀的設定。再加上目前普遍採用的日誌型檔案系統，要造成系統的損毀，可說是意外中的意外了。只是不管再多的解釋，事情的發生卻是不可爭辯的事實。在面對這類問題時，除了自我解嘲為運氣不好外，是否還能採用其他更積極的作為？

答案當然是有的，而且還是早就已經存在許久的作法。首先，當然就是老生常談的備份。除了定期的備份，針對重要資料甚至可以採用即時備援的架構，以避免備份時間點與意外發生時間點差異所造成的資料損失。備份與備援可以減少原始資料損失時所造成的影響，算是比較被動的作法。比較積極的作法，可以考慮將系統與資料分別存放在不同的檔案系統、不同的硬碟、甚至是不同的 RAID 陣列。事實上，在早期的 Linux 建構建議中，將系統與資料放在不同的檔案系統，一直是一個不可輕忽的作法。但是後來 Linux 的安裝過程過於自動化，連檔案系統的劃分也不需要管理者人工設定，所以這個建議事項越來越難被落實，甚至也很少聽到有人再提起。

無獨有偶的，前一陣子另外一位朋友公司的 ERP 系統，也因為停電而造成資料庫的損毀。資料庫損毀？是的，而且他們用的可是資料庫市場的領導品牌。更何況這可不是意外的停電，而是大樓事先公告的維護性停電。大樓公告被無視化、停電時剛好在進行當日資料庫的備份作業、斷電後重新供電不穩定、前一天資料庫備份無法使用...一連串的巧合，讓他們損失了不少的資料。又是運氣不好？是的，連我一個第三者都覺得運氣真的是太差了吧。

這個事件同樣也只能怪罪於運氣不好嗎？當然不是！大樓管理單位對於停電這麼重要的事情竟然只貼了公告，而沒有主動通知，肯定有所失職。但是大樓管理單位通常不是我們能夠控制的變數，所以我們更應該著力於我們可以控制的事項上。首先，是 UPS 系統的使用。UPAS 可不光是買了接上就行，包含電力不足時的自動關閉也是同樣重要的。此外，針對伺服器在停電後重新恢復供電的行為，是否該設定為自動啟動？還是應該設定為手動啟動？這也是一個值得仔細推敲的問題。最後，備份資料的確認，同樣是容易被許多系統管理者所忽視的重點工作事項。不管是透過雜湊值 (如 MD5) 來確保檔案的完整性，或者是透過匯入的動作來確保資料庫備份資料的正確性，都可以避免日後從口中發出 WTF 的憾事。

這兩個看似完全不相關的事件，同樣都因為新技術的導入，而忽略了原本系統就存在的風險。RAID 讓我們可以避免硬碟損毀所造成的意外，但是它卻無法避免其他意外的發生 (甚至 RAID 本身也可能出錯)。資料庫領導品牌強調他們的資料庫有多種機制可以確保資料不會損毀，但是依舊無法提供 100% 的保證。所以我們在面對這些技術時，千萬別因為這些新奇的保證而忘了其他存在的風險。採用多種保護措施，本來就是管理者用來應付風險的主要策略，千萬不要認為這是資源的重複投資與浪費而縮手。尤其在面對重要資料的保護時，小心、謹慎永遠是不嫌多的，將來有一天你會感謝自己曾經注意到這些"小細節"。