别为虚假的安全盲目乐观

衡量网络安全的标准应该包括保密性（Confidentiality）、完整性（Integrity）和可用性（Availability），一般我将它们合称为CIA。我们经常会谈论到前两个，但却很少注意可用性的问题。因此这次我想探讨一下可用性方面，比如容错和灾难恢复等主题——毕竟，如果服务或服务器无法正常使用，那么安全性又从何谈起呢？

    对于任何一个提供高可用性的服务，首先请确保有两台或以上的服务器，而且放置在不同的位置，不能被同一起灾难所毁坏。我知道有许多公司设置了多台服务器提供容错支持，首先这个想法值得鼓励；但不幸的是他们以为把服务器放在同一个城市里的不同地点就可以了。看看最近有关洪水和飓风的新闻，我不得不感叹他们白费了多大的力气，因为一个中小型灾难就会让整个城市断电。因此如果可能的话，请把多余的服务器放到不同的城市，当然如果能放到不同的国家就最好了。

    此外，服务器应该有多余的硬盘，考虑到性能因素，只要有可能的话，将日志和数据库存储到不同的物理硬盘上。如果硬盘支持RAID，那么请发挥RAID技术，让硬盘得到最好的性能。

    两台服务器总比一台好

    常有人问到应不应该使用服务器集群来支持服务？我的答案是两台服务器总比一台好，集群可以让两个或以上的主机共享相同的数据库、配置和服务名。集群的优点是当一个节点意外崩溃时，其他的节点会获取原始数据并继续处理请求，服务不会中断。但集群也有缺点，共享同一个数据库和配置可能会导致应用崩溃。

    我不会忘记我第一次将两台服务器进行集群时的情形，我花掉公司整整15万美元！当时为了追求一切的高性能和高可用性，我使用了包括一个分离底板通道（separate backplane channel）在内的多项措施来应付故障排除。我向CEO保证说，我们的应用运行可靠时间将高达百分之百。我的各位亲爱的读者，那时的我真是很傻很天真！结果就在第二天，一部分随机数据就崩溃了，并且集群中的每个关联的节点都随之崩溃——15万美元的集群束手无策。

    当然，虚拟化正在灾难恢复上大显身手。我知道有很多公司已经使用虚拟机对两个或以上的数据中心进行了虚拟化。如果某一台服务器或数据中心崩溃，只需要将服务移动到其他等待的虚拟服务器上，一些虚拟化厂商甚至提供了软件使整个过程无缝进行。

    也许在不久的将来，云服务会成为解决方案的一部分。但现在，云服务还不是那么成熟，出现问题后解决起来常常还不如自己动手。不过我想这些情况应该会随着服务可用性合同和其他服务条款等逐渐得到改善。（有关云安全方面的资料，请参阅：云安全你晕了么？）

    网络问题和最终用户的系统

    在网络安全方面，请回答下面这些问题。你的网络带宽充足吗？目前的带宽提供商能否保证你有两种不同方式接入公司网络？你有没有使用两家供应商？——无论怎样，请确保他们不使用同一根光纤接入你的办公大楼，要知道这是他们常做的事。请尽量减少由于光纤的问题造成的数据中断，这在网络故障中占了很大比例。

    还有，如果你在互联网上架设了高可用性的服务器，那么请问你有没有应用防御DDoS攻击的解决方案？你采用的反DDoS攻击的解决方案能否应付任何规模的攻击？还有即使你的解决方案可以阻止大规模攻击，你的ISP提供商能不能对付攻击行动，你会不会被他们抛弃以保存某些优先客户？如果你必须将服务器移走以躲开攻击，有没有事先安排好快速切换协议？需要多长时间来更新你的DNS入口？最后，这些问题你测试过吗？

    接下来——你的最终用户系统可靠吗？最终用户使用驱动程序是否稳定，在部署前经过了测试吗？我碰巧知道许多公司试图给用户提供一些花哨的新功能，结果却出现了更多的问题，最后得不偿失。我建议我的读者朋友们，一定要使用精确的测量方法来确定哪些系统最不可靠、哪些系统是最可靠的，并且牢记教训；应该时刻监测硬盘可用空间、网络使用率和CPU使用率，并且确认用户进行了备份。

    另外就是说到备份，你对备份进行过测试吗？许多公司在发现问题时已经为时已晚，昂贵的磁带备份系统成了摆设，管理员整日忙碌但就是忘了在之前测试一下数据恢复系统是否可靠。记住，测试、测试、再测试！

    警报系统崩溃怎么办

    如果电子邮件或电话系统瘫痪，监测系统是否能及时提醒你？还记得2000年那会儿Melissa、Iloveyou和Slammer等蠕虫疯狂入侵网络造成报警系统崩溃的情景吗？

    我记得当遭到Iloveyou蠕虫攻击时，我的传呼机不停的被关闭，一遍又一遍的收到“爱”的信号。我知道发生了大事情，但手机无法工作。我试图使用座机，它也已经失效了。来自互联网的蠕虫一遍遍的冲击电子邮件和短消息系统。我花了一个多小时才恢复了座机通讯——而我的手机在当天的大部分时间仍然无法使用。

    如果再次发生什么大事情，不要指望互联网能够正常运行，它没有你想的那么强大。你会知道碰上了大问题，但无法联系上任何人，也不可能直接把技术人员带来现场解决问题。

    在这种情况下该怎么做？我不能肯定。在一个案例中，我们不得不用高空呼叫系统与对方进行沟通，最后解决问题的办法是发送手写的标语！关键是要预测那些没法预测的，将意外情况纳入反应计划中。出现紧急情况是首先联系谁？有没有设置第二、第三和第四种沟通方式？当然，大家可以把RFC 1149（不明白吗？请51CTO.com读者尽快学习一下这个标准；当然，如果您已经在上个星期愚人节那天看过了Google的《2009谷鸽鸟看计划》，那您应该已经明白了）作为最后一种，因为据说这些信鸽在巴西监狱也可以工作。

    当然，你很有可能会觉得我说的是不是有点严重了，尤其是你的公司在最近这次传说会有大麻烦的Conficker病毒中并没受到什么影响。但我认为，我们不得不防！在过去的五六年里蠕虫没有大规模爆发，这也带给我们一个虚假的安全感。很多企业自以为有办法应对危机，但是也许只是因为我们很幸运——无论如何，请确认你的可用性和反应计划是最新的，并且随时准备应对大块头蠕虫的挑战。