前段时间单位大张旗鼓的网络安全活动结束了，在几十份划着红圈和签名的协议中结束，协议的内容无非是某网站责任人是谁以及不得如此禁止那么云云，用这样的方式来对待目前的网络安全问题，着实可笑了一些。网络安全是个整体性的事情，说泛点从设计开发测试运维到系统网络环境等等，从另一方面来说更是一个技术活儿，不是搞一两次这样的“运动”会就能整好的。说到底，hacker是看不到你的红圈圈的，说到底要在各个层面增加你的防御能力才行。

其实，现在面临的安全问题很现实。

a。分网站泛滥。开通网站（领导们经常把网站和域名混为一谈，只能苦笑）的程序随意，屁大点的一点信息都要弄个新域名搞个网站，很多网站在经过一段时间运行之后就慢慢沉积，老旧过期脚本的隐患问题就非常大的，以前不太注意的脚本漏洞就会影响同服务器的其他网站，同时数据库信息也没有及时维护更新。

一个庞大的网站群需要有一个良好的进入和退出机制，我想这应该是运维机制的一部分，网站发布需要存档相关系统xin信息，确定文件版本和相关开发的更新运维人员，并在运维过程中坚持更新记录。当一个网站不能满足业务需要之后，需要合理退出，在文件脚本数据库在备份服务器存档之后从前台服务器退出掉，避免陈旧脚本的影响。

b。程序开发人员缺乏安全意识，过于注重web脚本的结果呈现，或者是任务完成功能实现即可，这样的产品发布之后后患无穷。一个web产品完成之后也没有很完整的安全测试，一个简单的功能性操作性测试就完了。

所有的开发和运维人员要组织安全培训，而且是定期的，不用太长我想三个月一次即可，不然没法积累。而且脚本编码的安全合格性需要有个考核，和业务考核挂钩一下，慢慢养成编码习惯。产品上线之前也需要加入安全测试环节，不通过安全测试的产品是不允许在前端发布的。

c。web产品的系统化程度太低，从文件上来举例，没有一致的文件目录规范，哪些文件目录是可写的上传类的，哪些文件目录是配置性的。造成了每个网站的结构不尽相同，权限设置只能用最低标准来符合。同时，为了迁就某一特殊应用或者用户要求，可能在权限设置方面造成了一些漏洞。总体来看是缺乏精细和严格的运维制度。

看着到手的网络安全责任书，匆匆的想了几点，下次从实际的系统运维上再整理下。