【51CTO.com快譯自Roger Grimes的博客】衡量網絡安全的標準應該包括保密性（Confidentiality）、完整性（Integrity）和可用性（Availability），一般我將它們合稱為CIA。我們經常會談論到前兩個，但卻很少注意可用性的問題。因此這次我想探討一下可用性方面，比如容錯和災難恢復等主題——畢竟，如果服務或服務器無法正常使用，那么安全性又從何談起呢？

對于任何一個提供高可用性的服務，首先請確保有兩臺或以上的服務器，而且放置在不同的位置，不能被同一起災難所毀壞。我知道有許多公司設置了多臺服務器提供容錯支持，首先這個想法值得鼓勵；但不幸的是他們以為把服務器放在同一個城市里的不同地點就可以了。看看最近有關洪水和颶風的新聞，我不得不感嘆他們白費了多大的力氣，因為一個中小型災難就會讓整個城市斷電。因此如果可能的話，請把多余的服務器放到不同的城市，當然如果能放到不同的國家就最好了。

此外，服務器應該有多余的硬盤，考慮到性能因素，只要有可能的話，將日志和數據庫存儲到不同的物理硬盤上。如果硬盤支持RAID，那么請發揮RAID技術，讓硬盤得到最好的性能。

兩臺服務器總比一臺好

常有人問到應不應該使用服務器集群來支持服務？我的答案是兩臺服務器總比一臺好，集群可以讓兩個或以上的主機共享相同的數據庫、配置和服務名。集群的優點是當一個節點意外崩潰時，其他的節點會獲取原始數據并繼續處理請求，服務不會中斷。但集群也有缺點，共享同一個數據庫和配置可能會導致應用崩潰。

我不會忘記我第一次將兩臺服務器進行集群時的情形，我花掉公司整整15萬美元！當時為了追求一切的高性能和高可用性，我使用了包括一個分離底板通道（separate backplane channel）在內的多項措施來應付故障排除。我向CEO保證說，我們的應用運行可靠時間將高達百分之百。我的各位親愛的讀者，那時的我真是很傻很天真！結果就在第二天，一部分隨機數據就崩潰了，并且集群中的每個關聯的節點都隨之崩潰——15萬美元的集群束手無策。

當然，虛擬化正在災難恢復上大顯身手。我知道有很多公司已經使用虛擬機對兩個或以上的數據中心進行了虛擬化。如果某一臺服務器或數據中心崩潰，只需要將服務移動到其他等待的虛擬服務器上，一些虛擬化廠商甚至提供了軟件使整個過程無縫進行。

也許在不久的將來，云服務會成為解決方案的一部分。但現在，云服務還不是那么成熟，出現問題后解決起來常常還不如自己動手。不過我想這些情況應該會隨著服務可用性合同和其他服務條款等逐漸得到改善。（有關云安全方面的資料，請參閱：云安全你暈了么？）

網絡問題和最終用戶的系統

在網絡安全方面，請回答下面這些問題。你的網絡帶寬充足嗎？目前的帶寬提供商能否保證你有兩種不同方式接入公司網絡？你有沒有使用兩家供應商？——無論怎樣，請確保他們不使用同一根光纖接入你的辦公大樓，要知道這是他們常做的事。請盡量減少由于光纖的問題造成的數據中斷，這在網絡故障中占了很大比例。

還有，如果你在互聯網上架設了高可用性的服務器，那么請問你有沒有應用防御DDoS攻擊（distributed-denial-of-service，分布式拒絕服務攻擊，可參閱51CTO.com DDoS防御專題）的解決方案？你采用的反DDoS攻擊的解決方案能否應付任何規模的攻擊？還有即使你的解決方案可以阻止大規模攻擊，你的ISP提供商能不能對付攻擊行動，你會不會被他們拋棄以保存某些優先客戶？如果你必須將服務器移走以躲開攻擊，有沒有事先安排好快速切換協議？需要多長時間來更新你的DNS入口？最后，這些問題你測試過嗎？

接下來——你的最終用戶系統可靠嗎？最終用戶使用驅動程序是否穩定，在部署前經過了測試嗎？我碰巧知道許多公司試圖給用戶提供一些花哨的新功能，結果卻出現了更多的問題，最后得不償失。我建議我的讀者朋友們，一定要使用精確的測量方法來確定哪些系統最不可靠、哪些系統是最可靠的，并且牢記教訓；應該時刻監測硬盤可用空間、網絡使用率和CPU使用率，并且確認用戶進行了備份。

另外就是說到備份，你對備份進行過測試嗎？許多公司在發現問題時已經為時已晚，昂貴的磁帶備份系統成了擺設，管理員整日忙碌但就是忘了在之前測試一下數據恢復系統是否可靠。記住，測試、測試、再測試！

警報系統崩潰怎么辦

如果電子郵件或電話系統癱瘓，監測系統是否能及時提醒你？還記得2000年那會兒Melissa、Iloveyou和Slammer等蠕蟲瘋狂入侵網絡造成報警系統崩潰的情景嗎？

我記得當遭到Iloveyou蠕蟲攻擊時，我的傳呼機不停的被關閉，一遍又一遍的收到“愛”的信號。我知道發生了大事情，但手機無法工作。我試圖使用座機，它也已經失效了。來自互聯網的蠕蟲一遍遍的沖擊電子郵件和短消息系統。我花了一個多小時才恢復了座機通訊——而我的手機在當天的大部分時間仍然無法使用。

如果再次發生什么大事情，不要指望互聯網能夠正常運行，它沒有你想的那么強大。你會知道碰上了大問題，但無法聯系上任何人，也不可能直接把技術人員帶來現場解決問題。

在這種情況下該怎么做？我不能肯定。在一個案例中，我們不得不用高空呼叫系統與對方進行溝通，最后解決問題的辦法是發送手寫的標語！關鍵是要預測那些沒法預測的，將意外情況納入反應計劃中。出現緊急情況是首先聯系誰？有沒有設置第二、第三和第四種溝通方式？當然，大家可以把RFC 1149（不明白嗎？請51CTO.com讀者盡快學習一下這個標準；當然，如果您已經在上個星期愚人節那天看過了Google的《2009谷鴿鳥看計劃》，那您應該已經明白了）作為最后一種，因為據說這些信鴿在巴西監獄也可以工作。

當然，你很有可能會覺得我說的是不是有點嚴重了，尤其是你的公司在最近這次傳說會有大麻煩的Conficker病毒中并沒受到什么影響。但我認為，我們不得不防！在過去的五六年里蠕蟲沒有大規模爆發，這也帶給我們一個虛假的安全感。很多企業自以為有辦法應對危機，但是也許只是因為我們很幸運——無論如何，請確認你的可用性和反應計劃是最新的，并且隨時準備應對大塊頭蠕蟲的挑戰。

【51CTO.com譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】

【編輯推薦】

1. 專家支招：構建安全服務器環境阻止黑客攻擊
2. 專題：打造安全服務器
3. 如何打造安全穩定的FTP服務器

原文：Are you ready for the big one?  作者：Roger Grimes