一份安全运维规范文档写了80页，锁在文件柜里从来没翻开过——这是不少企业的真实写照。制度不落地等于没有制度，问题出在写制度的人不懂一线运维，写出来的东西没法执行。
权限管理：最小化原则怎么落地
最小权限原则怎么操作？三个抓手。服务器访问权限分三级：一线运维只有应用目录读写权限；二线运维有数据库读写权限但无系统管理权限；安全管理员有root权限且通过堡垒机操作，全程录屏审计。给权限时问一句“他真的需要这个权限吗”，答案不是肯定的就不给。
密码管理统一用密码管理器（如1Password团队版），禁止写在便签上、存在Excel里或通过微信传。所有服务器密码每90天强制轮换，轮换记录留档。第三方供应商驻场或远程支持时，开通临时账号，设有效期到期自动失效，权限限制在必要范围内，不能给全量权限。
变更流程：每次上线都是安全考验
未受控的变更是安全事件的一大根源——开发直接在生产环境改代码、运维临时关防火墙测试、第三方接口变更没通知。管住变更就堵住了一大半风险。
标准变更流程：开发提交申请写明变更内容、影响范围、回滚方案；技术负责人审批；运维在维护窗口内执行；变更后验证并记录。紧急变更走快速通道，事后补审批。代码上线前必须过三道安全检查：SonarQube静态代码扫描、SCA第三方组件漏洞检查、DAST测试环境漏扫，全部通过才允许上线。
日常巡检与应急预案
建立三层巡检机制。每日巡检5分钟：查服务器资源使用率、网站访问状态、安全告警未处理项、备份任务执行情况。每周巡检30分钟：系统补丁更新情况、WAF拦截规则是否需要更新、SSL证书有效期是否不足30天、异常登录记录分析。每月巡检2小时：全量漏洞扫描、权限审计清理离职人员和过期账号、安全日志分析、巡检报告汇总。
巡检要有明确标准。比如“检查备份”不是看一眼有没有报错，而是实际从备份中恢复一个文件验证可用性。应急预案每年至少演练两次，模拟DDoS攻击、数据库被拖库、核心服务器宕机等真实场景。每次演练后复盘修订，经过两三轮打磨的预案才算真正可用。