网站安全管理制度

去年某电商平台被拖库，网站攻击者只用了一个弱口令就进了后台，安全把几百万条用户订单打包带走。管理事后复盘，制度问题不在防火墙，网站也不在代码漏洞，安全而是管理运维图省事，把测试环境的制度账号密码直接搬到了生产环境，一用就是网站两年。这种事说出来像段子，安全但它每年都在发生。管理

网站安全管理制度不是制度挂在墙上的文件。它得能管住人、网站管住代码、安全管住服务器上的管理每一条命令。我见过太多团队把制度写成八股文，结果开发照样在代码里硬编码数据库密码，运维照样用root跑Web服务。制度一旦跟实际操作脱节，就等于没有。

账号和权限：别让一个人拥有全部钥匙

核心原则就一条——最小权限。谁需要什么权限，就给什么权限，多一点都不给。具体怎么做？生产环境的数据库账号，开发人员不能有；服务器SSH登录，禁止root直接连；所有操作账号必须实名，离职当天回收。有个做金融的朋友告诉我，他们内部有个规矩：任何人对生产环境的写操作，必须经过跳板机，且全程录屏。听着夸张，但真出事的时候，录屏就是证据。

密码策略也得硬性规定。长度至少12位，大小写加数字加符号，90天强制换一次。别嫌麻烦，弱口令是攻击者最喜欢的东西，没有之一。

代码与上线：安全不是上线后才想的事

很多漏洞是写代码时埋下的。SQL注入、XSS、越权访问，这些老问题至今还在OWASP Top 10里挂着。制度里得写清楚：代码提交前必须过静态扫描，高危漏洞不修复不允许合并。上线前做一次渗透测试，哪怕只是用开源工具扫一遍，也比裸奔强。

另外，配置文件里严禁出现明文密码。用环境变量也好，用密钥管理服务也好，总之别把密码写在代码里。GitHub上每天都有因为提交了包含密钥的配置文件而被盗刷的案例，一搜一大把。

日志与监控：出了事得知道谁干的

没有日志的安全制度是瞎子的拐杖。Web访问日志、数据库操作日志、系统登录日志，至少保留180天。关键操作要有审计轨迹，比如谁在什么时候删了哪张表，谁改了防火墙规则。监控方面，异常登录、异常流量、异常文件修改，都得有告警。别等用户数据在暗网卖了才发现自己被黑了。

应急响应：别等出事才翻手册

制度里必须有一页写清楚：发现入侵后，第一步做什么，第二步做什么，谁负责对外沟通，谁负责取证。我见过一个团队，被入侵后第一反应是重装系统，结果把所有证据都抹掉了，连怎么进来的都不知道。正确的做法是先隔离受影响机器，保留内存和磁盘镜像，再逐步排查。

还有，定期演练。每季度搞一次模拟攻击，看看团队能不能按流程走下来。演练不是为了好看，是为了真出事的时候不慌。

说到底，网站安全管理制度的核心就两个字：落实。写一百页不如执行一条。技术手段再强，也架不住人偷懒。制度要简单、具体、可检查，最好每一条都能对应到一个具体的操作动作。否则，它就是一张废纸。