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（大多有专门的团队负责）。但无论如何，做架构的还是需要清晰的知道这些规范是什么样的。
//最近发现latex写规范文档简直是神器
//我前些天分别在三个群聊里请教了如何评估安全架构组和安全架构师输出的问题。事实证明，没有经历过就去谈经验，很难对的上。回头单开一篇文章讲讲怎么衡量。