我在去年关于企业安全观的文章里就总结过，做安全架构是需要管理，运营，技术互相配合的。那怎么配合，技术怎么实现总归是有一个参照物/底线在的。如果什么都张口就来，时日渐久也就没什么”架构”可言了。而文档作为一种交付形式，可以成为最基本的参照物。今天简单以架构视角看看怎么建设安全规范。
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个月内解决）等。
规范的建设是作为底线存在的，不同的底线组成了框架。我们期望能够尽量构建一个弹性的框架，覆盖常见的场景。但显然不可能所有业务都能够在这个框架内。做为架构师，也只是去尝试选择最适合的方案，而不是最好的方案。
了解了Policy，Procedure，Standard也就知道架构评审中的Checklist是怎么来的，那些SDLC平台中的知识库来自哪里了。除此之外还有一个值得思考的问题，做Policy的（Policy的制定不一定全部来自架构团队，有的来自Compliance团队。）怎么才能避免不和Operation以及Technical的东西脱节。除了建立反馈机制外，也依旧需要了解一定的技术细节，例如知道什么样的工具通过什么样的操作达到了什么样的效果。
虽然讲了这么多，事实上小厂是基本还没达到制定policy的条件，而大厂一般又不需要从零建设Policy（大多有专门的团队负责）。但无论如何，做架构的还是需要清晰的知道这些规范是什么样的。
