本文作者：厦门大学郑海山

为什么说到网站群，网站群蛮老了，现在提这个感觉是在凑公众号篇数。去年我遇到有个学校计划采购很多安全设备，但是一问下去，网站群还不在采购计划内。有些学校就算有，也没有100%覆盖，对于安全来说，99%跟0%差别不大。对于一个高校的网站防护，首先是摸清家底，评估风险。如果你的网站后台是百花齐放，那省事了，不用评估了，没有任何意义。

理想情况是新闻发布性质的网站和信息系统分开。

新闻发布性质的网站和信息系统复杂度是不同的。保护的难度不同，新闻发布可以生成静态只读；开放度是不同的。新闻发布是面对全世界开放的，而信息系统可以在小范围内开放，在特定时期开放。他的入口可以是新闻发布性质的网站，在特殊时期被关闭了用户也可以得到有效通知。

接着是所有的新闻发布性质的网站进入网站群统一管理。网站群才是治标治本的方法。与其让各个学院花钱或不花钱冒出一个CMS，你去使用IDS，WAF去做保护，首先你要知道有了这么一个站点，然后你要去匹配测试一些规则，也有很大概率会有误报，然后对方还会更新，中间加了你WAF这一层导致查错很麻烦，你会跟对方扯来扯去耗费了很多精力还是搞不好。你要为他们的问题买单。

新闻系统是否真的简单

很多人都认为就一个新闻发布平台，能有什么难的？确实，年轻人的第一个编程课后大作业是图书馆系统，因为新闻发布系统太简单以至于排不上号，至少图书馆系统还涉及到库存和逾期计算。所以是个人都可以写一个新闻发布系统。但是不要跟我扯新闻系统，我可以堆出一大堆术语让你发现“对那种力量一无所知”。

就算你功能性都可以不要，再扯到安全，部署环境是否安全？程序代码呢？管理端是否隐藏？密码是否有防止暴力破解？SQL注入？XSS？CSRF，文件上载？权限保护？调试信息隐藏？根据IP进行访问限制？计数器防刷机制？附件删除同步删除？

我见过太多的网站会把这些安全问题都犯过一遍，虽然你可以用一个开源的Wordpress，不安装插件，不做二次开发，系统和Wordpress打开自动更新，完美部署，这可以说是非常安全了，但是面对几百个站点筛选成本太高，唯一只能一刀切。

网站群限制也很多

网站群没法100%覆盖是由于部分目前的新闻网站有些要求网站群无法满足，这是必须承认的，但是网站群他是为安全而生的，功能性和个性化是可以妥协的。10年前我们采购网站群的时候还只是提“网站群是一个建站平台，无需编程，通过拖拽就可以建立一个站点”，很像是增值服务，但是现在看来越来越要变成是基础套餐了。

• 你：“管理端浏览器兼容性不好。”网站群：“我很安全。”

• 你：“模板结构不够灵活，标签太少，页面做出来很难看。”网站群：“我很安全。”

• 你：“没有会议报名功能。”网站群：“我很安全。”

• 你：“师资个人介绍页面得管理员修改。”网站群：“我很安全。”

• 你：“我做一个CMS投入90%的经费做安全。”网站群：“我很便宜又很安全。”

所有的网站都进入网站群了

网站群的安全性就非常重要了。采购一个市场占有量大的网站群，做好三级等保，不犯低级错误，CVE天灾人祸出来更新，是没有什么大问题的。

大连理工大学李先毅的《看新模式如何破解Web安全老大难》这篇文章写得很到位，他们独立了开发、管理、发布三套服务器，职责分离，通过单个网站网站包的导出导入完成开发到部署的切换，又分离了重要和非重要的网站，这是我开始没有想到的。当然也可以再商榷，以我的经验，维护这么多服务器，三级等保加固和日常巡检维护工作量是很大的。如果是我，我会考虑（为什么是考虑？因为我打算这么做，等看是否有其他反馈）只有数据库、开发、管理、发布，前端再来个Nginx负载均衡，全站HTTPS在Nginx做。因为管理区分多台要看后台数据库是不是同一个，如果是同一个，那区分意义不大，不是同一个，新闻聚合和新闻多站点发布投递又是问题。而且应当信任网站群，不会有网站之间隔离逃逸的问题。而通过前端负载均衡，DNS配置压力较小，整个部署简化，还可以做访问热点加速，访问日志也比较方便统计。如果怕鸡蛋都在一个篮子不抗DDoS，那可以多个Nginx而不是多个发布。所有的开发、管理、发布全部限制对外主动发起请求，系统更新通过代理更新，配置全部走自动化配置。堡垒机还是必须，WAF和IDS等就可以考虑撤离了。

好了，新闻性质的网站全部纳入网站群了，你现在可以有精力来关注信息系统的安全了，数据泄露问题了。