网站群在保障高校网站安全中的重要作用
为什么说到网站群,网站群蛮老了,现在提这个感觉是在凑公众号篇数。去年我遇到有个学校计划采购很多安全设备,但是一问下去,网站群还不在采购计划内。有些学校就算有,也没有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等就可以考虑撤离了。
好了,新闻性质的网站全部纳入网站群了,你现在可以有精力来关注信息系统的安全了,数据泄露问题了。