安全规范建设指北
2022-11-16 20:7:15 Author: mp.weixin.qq.com(查看原文) 阅读量:10 收藏

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

领域与范围

  • 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(大多有专门的团队负责)。但无论如何,做架构的还是需要清晰的知道这些规范是什么样的。


文章来源: https://mp.weixin.qq.com/s?__biz=Mzg3ODAzNjg5OA==&mid=2247485102&idx=1&sn=69cb1e60407de1d456a35d2157c64bb2&chksm=cf189463f86f1d75fe9d884c2e92d74401fea1411c1b384dba42446f22b1e73166028106a3b3&scene=58&subscene=0#rd
如有侵权请联系:admin#unsafe.sh