安全规范建设指北

0x01 前言

我在去年关于企业安全观的文章里就总结过，做安全架构是需要管理，运营，技术互相配合的。那怎么配合，技术怎么实现总归是有一个参照物/底线在的。如果什么都张口就来，时日渐久也就没什么”架构”可言了。而文档作为一种交付形式，可以成为最基本的参照物。今天简单以架构视角看看怎么建设安全规范。

0x02 正文

领域与范围

• Policy 是做架构主要参考和依赖的，对比 procedure 和 standard 来说更为抽象（使用 xx 算法或者实现 xx 控制）且无关技术实现的（使用 xx 工具），在编写 Policy 时还需要具备一定的弹性（例外情况）。安全策略的制定主要来自架构团队，需要架构师做到对不同领域的安全技术和应用场景（例如常见的数据分类在 web3/crypto 中的是不是要调整一下）以及优劣等都了然于胸，属于 High Level Design。以 Crypto 管理举例，既要精通密钥的生命周期管理（怎么产生、存储、备份、恢复、销毁等），也要熟知各种应用场景（对称密钥哪些算法，用于加密还是完整性校验，非对称哪些用于认证还是加密，长度的控制）。这里还可以以此讲下架构中的弹性设计是如何在策略中体现的，比如策略制定的时候规定了不允许使用 DES，填充也不能用 CBC。那以这个策略为分界线，在此之前肯定存在一些遗留系统是使用。而策略的生效边界是 Relase/Approve 之后。所以针对这部分就需要注明在策略中，某些弱的算法仅允许遗留系统使用，针对新的业务系统必须遵守新的规范。同样的策略可以要求集团所属的企业（实际情况是 BU 间都不一定满足），但是要求不了合作方（或者说合作方不能完全遵守的，类似的有开放平台、做市商，投资机构之间的数据流转等）。比如要接某家的人脸识别，虽然在策略里定义了针对 X 类数据必须使用 AES256 以上进行数据加密。这时候突然发现对方接口只支持 3DE 怎么办？在业务优先的情况下，肯定是要放行的。这就需要在策略制定时提前规划进去，预留一个例外（Exception）情况的通道。比如获得 XX 负责人的批准，除此之外针对违反了基线的 Exception 仅允许 1 次且只能在 xx 时间内进行修复。类似的如果以网络安全管理，既要定义怎么划分哪些安全区，也要定义什么应用可以放在什么区中，以及访问什么区域需要什么样的权限等等，同时针对网络配置的备份恢复，日志和流量镜像的存储等等。那针对这些边界区之间的规则如果还要做特殊的网络开放，就需要通过特殊的 Exception 流程完成。

• Procedure 是做运维运营必须要遵守的，一般是针对各种平台、产品、工具、系统等制定在不同场景下的标准流程。一般编写 SOP 的是一线工程师的 Manager/Leader。当然更多的时候可能是一线工程师编写，Leader 进行 Review。SOP 的编写要求对所处领域的技术实现和现有资源充分的了解，比如说写设备加固，系统加固的流程。怎么禁用未使用的协议，怎么传输日志到集中化日志平台。怎么备份，怎么恢复等等。（前面 policy 会指明应该具备备份恢复，且备份管理应该是多久。这里的备份指的是具体备份的流程，比如使用 xx 命令定时产生备份文件，进行 hash 校验后通过 xxx 同步到 xxx 位置。github 备份有一份流程，DB 也有一份流程，jforg 又有一份流程等等）。除此之外流程的产生还有很大一块是在安全运营以及应急响应。例如接收到钓鱼邮件的处理过程，端上病毒软件的处理等。这些具体到场景的工作流程，写起来还是比较容易的，但是有些安全工程师做运营的时候往往不愿意去输出流程。一是盲目自信，二是抵触文档工作（不是技术工作） 。而实际经验告诉我，缺乏 SOP 会在应急的时候造成对个人能力（实际应急的员工）的依赖，而压力之下又容易缺乏系统思考。

• Standard 指代的更多是技术标准，包含了标准配置的定义，基线的定义等。前面提到了制定管理约束的 Policy，制定了具体场景下对不同工具的使用 Porcedure。而 Standard 就是针对这些工具，产品提供的具体标准配置文档。举例来说，假设前面 policy 提到了备份，procedure 提到了用 ssh 备份，那公司内 ssh 相关的 standard 里就要规定了默认的 ssh 配置。比如使用 SSH-2 以上的版本，曲线 25519，禁用 3des-cbc 的密码，使用 hmac 不使用 md5 等等这些都是基础的技术基线。类似的，如果使用 TLS，使用 TLS1.2 以上，使用哪些允许的 Ciphersuite，Ciphersuite 的选用顺序，服务端上怎么配，客户端（IOS，Android，OSX 等）怎么配置，证书来自哪里，证书的选择及配置等等。一般来说行业都会提供一定的技术标准文档和最佳实践（无论是 policy 还是 standard，都会涉及到去参考行业标准）。可以根据这些标准制定出企业内所适用的。

格式与内容

格式上的字体选择，字号大小就不讨论了。一般首页指明规范的名称，编号，版本号，批准情况，历史记录等。页脚标注仅限内部使用，页眉放置编号及名称，同时加上水印，如果是国际化的企业，还需要准备多语言版本。下面是截图。

一般内容来说会包含以下几点：

• 概述和目的

• 通用范围

• 关键定义

• 角色和职位描述

• 审批要求

• 实施和例外情况

需要注意的是在制定的时候需要参考国际规范，也要参考 domestic 的。例如 MLPS2.0，密码法等等。除此之外还需要注意不能有模棱两可的语言，要明确场景，场景约束。同时尽量官方，也不能有你我他这样的描述。

审计与例外

规范本身也需要具备生命周期管理的。什么时候更新，经过什么样的流程发布，什么情况下规范不再适用等等。所有发布的规范（策略，流程，标准）都需要经过批准（内部区分出 Release 和 draft 版本），一旦 Approve 并 Release，不论是一线工程师，还是管理层都默认必须遵守该规范。但如前文所述，一定是会存在例外情况的，那针对例外情况可以去提供 exception 流程，只不过这个流程一定是具有较高的成本。设置 Exception 的准入，提高 Exception 的批准节点（例如条线负责人），设置缓解的期限（例如 3 个月内解决）等。

0x03 总结

规范的建设是作为底线存在的，不同的底线组成了框架。我们期望能够尽量构建一个弹性的框架，覆盖常见的场景。但显然不可能所有业务都能够在这个框架内。做为架构师，也只是去尝试选择最适合的方案，而不是最好的方案。

了解了 Policy，Procedure，Standard 也就知道架构评审中的 Checklist 是怎么来的，那些 SDLC 平台中的知识库来自哪里了。除此之外还有一个值得思考的问题，做 Policy 的（Policy 的制定不一定全部来自架构团队，有的来自 Compliance 团队。）怎么才能避免不和 Operation 以及 Technical 的东西脱节。除了建立反馈机制外，也依旧需要了解一定的技术细节，例如知道什么样的工具通过什么样的操作达到了什么样的效果。

虽然讲了这么多，事实上小厂是基本还没达到制定 policy 的条件，而大厂一般又不需要从零建设 Policy（大多有专门的团队负责）。但无论如何，做架构的还是需要清晰的知道这些规范是什么样的。