当我们在谈安全默认时我们在谈什么

预览

安全默认（Security By Default）是一个老生常谈的话题。今天随便聊聊在安全架构设计中安全默认起到了什么作用。便于理解依旧会从网络、应用、数据几块去介绍，实际落地的时候会从具体场景考虑，例如主机的默认安全，邮件的默认安全，存储的默认安全等等。另外涉及物理机房时可能还需要考虑敏感业务的机柜隔离，专线隔离，机柜单独上锁等，这一块不在此赘述了（主要是不懂）。

1. 设计中的一些默认

安全默认可以简单看作一个从策略设计到工具实施过程（注意安全默认实际上对工具非常依赖）。在设计之初，会有各种针对网络、应用、数据的规划。这时候只是为了提供一个默认安全的愿景，而真正具备这个能力，是在说服各方达成一致并完成实施之后。以网络为例，假设已知的一些控制手段有DLP，PROXY，Firewall，WAF，IDS等等，那针对Zone如何设计分区，Zone间的访问涉及到的哪些安全控制，以及采用什么访问规则。一旦确定之后就形成了对网络层面基本的安全默认。即解放了安全运营人员次次开防火墙配置规则，也解放了员工为每个业务提工单申请，同时也减轻了后续规则审计的成本。下面逐个展开。

1.1 网络

对于网络来说，会首先关注Zone的业务属性，并由此去设计安全控制，这是贴近业务的一个过程。我们可以思考的点有：在DMZ到HRZ之间会使用哪些安全控制？从Internet访问DMZ时呢？以及从DMZ访问Internet时又分别经过哪些安全控制等等。而且一旦在默认形成之后，所有的例外流程都应该采用工单记录，在遵循变更管理的情况下进行配置。但有时候也不得不承认，即便是良好的设计，在一定程度的“例外”运营之下，也会变得面目全非。

除此之外，我还简单列了一下可能在设计时关注的点，并使其达到安全默认的效果。

• 应用默认只允许放在符合对应业务等级的Zone中

• 高等级数据所在的Zone不能流向存放低等级数据的Zone，数据默认只能流向更高等级的Zone

• 不同DC之间同样的Zone具备同样的安全控制，但不能默认无条件打通Zone

• 数据从生产网流向办公网环境时仅允许到达Confidential区

• Zone A和Zone B之间访问默认不需要开通防火墙或者Zone X和Zone Y之间默认只允许哪些端口列表（e.g. 21，443）

• 所有传输协议默认使用具备TLS的版本，HTTP->HTTPS, LDAP->LDAPS等

• 内部传输默认采用PKI-Signed的证书, 外部采用Public CA Signed的证书

• 内外访问进行充分的隔离，一个有内外访问需求的服务需要设置不同的访问端点

• 所有对服务器的访问只能通过堡垒机所在的Zone

1.2 应用

对于应用来说，实际会更多的通过在SDLC去覆盖安全能力以实现安全默认和自动化。无论是架构评审的准入机制（应用必须经过CICD可能不一定是安全来拍板），以及发版的基本要求，在一定程度上都是实现了安全默认。

• 新的组件引入必须进行评估，不得使用未评估的组件

• 使用统一的依赖源，并对依赖源进行检查

• 采购的系统本地部署时需要替换统一内部组件

• 为全端集成相应的安全SDK

• CICD必须经过SCA，SAST，IAST，Docker Image Scan，（往左还可以在本地Dev时进行扫描，往右拿到APK/APP包进行扫描）

• 高敏业务的应用存在的漏洞必须在X时间内修复

• 存在Y情况是不允许应用上线的

• 高敏业务的应用必须通过代码审计以及渗透测试

• 应用的敏感配置文件必须放在Vault里

• 应用在bootstrap时需要校验完整性

• 应用之间通过证书及mTLS进行认证

• 应用不允许直接暴露NodePort，仅允许通过LB或API Gateway暴露

• 凡是走CICD暴露的web服务，自动覆盖网络层面的安全能力。（WAF，Anti-DDOS）等等

1.3 数据

对于数据而言，属于灯下黑的状态。看似在设计上非常的关注对数据的保护，但在安全默认上实际一直都是一个被忽略的点。我们很多情况下都会关注到应用的代码扫描和网络的传输加密。但往往会忽略不同等级数据的流动。例如针对等级为X及以上的数据不能离开所在的Zone，且等级为X及以上的数据仅允许在xx情况下访问。

• 针对等级为X以上的数据不得进行存储

• 针对等级为X以上的数据不得进行分享

• 针对哪些等级的数据禁止本地存储（PC、U盘、移动介质等）

• 针对等级为X以上的数据默认进行加密，且必须使用在HSM内的密钥

• 不允许使用弱密码算法

• 针对等级为X及以上的仅在严格授权下才能访问

• 证书生成密钥生成需要在什么环境下

• 证书分发密钥分发需要使用什么工具

• 系统日志必须集成到日志中心

需要注意的是实际落地过程中不会以数据/应用/网络的形式，而是更多的考虑具体的系统以及场景。以主机安全举例，会在制作标准镜像时将配置好的安全工具打包进去，对于业务方并不会感知这些工具的存在。例如可把EDR，HIDS，证书链等放到主机镜像中，把DLP，SASE，UEM放到Laptop的镜像里。一旦镜像变成Instance时，那么默认的的安全防护也都启动了。再以应用代理为例，对于业务来说只是通过代理进行了出网访问，而实际过程入向流量经过了AV Scan，出向流量经过了DLP。当然有时候不是绝对的无感，可能需要提前和业务方同步好场景，并在上线之前完成生产中一些安全设备的配置。

2. 总结

在谈及应用和数据两块的安全默认时，文中一直在说”等级为X的数据“，“Y类型的业务”，是为了表示应用和数据的安全默认需要充分的综合业务场景，不同的业务属性X、Y会带来不同等级的安全控制。文中列举的一些设计规则也仅仅只是抛砖引玉，从设计的视角出发，至于产品的选型，实施运营等等还需要进一步考虑。例如需要把规则配置到Firewall，HIDS，SAST等工具中。另外也需要注意对安全设备、安全运营工程师本身也要纳入到已有的安全防御体系里，避免自身不够安全。例如审计业务的日志，也要审计安全自己的日志。分离业务系统的权限，也要分离安全系统的权限。 在实际做设计的时候一定要谨记贴近业务，服务于业务（而不是服务于同事）。实际上正是这些预置的条条框框形成了所谓的安全默认，如果没有这些条条框框，那就需要在每一次交互时去完成相应的校验，也就是Zero(No) Trust。同时也不难发现安全默认是为了使安全能力更加无感，降低对业务的侵入性。通过用空间换时间的方式来减少对业务的阻碍（提前铺好防御的设施，以便业务更快迭代），相反安全左移则是通过时间换空间的方式让安全部门能够更及早的参与进去（提前参与业务中去，以便尽早的把风险解决在上线之前，并在遇到威胁时有更多的反应空间，例如在线上运营时发现的漏洞规则通过waf阻断和通过代码审计并完成修复的效果是完全不一样的）。

仔细想想，为什么会有Security By Default的概念，接着出现Security By Design的概念（是不是好的Design才能去实现Security By Default），最后又要Shift To Left。因为发现Default在Runtime的效果不如在Architecture以及CICD等阶段。另外针对SAAS服务（厂商的Runtime），做评审和准入时，似乎看起来只能由SAAS厂商来控制。这个时候所谓的安全默认能做哪些事情？不妨思考一下企业还能做些什么能达到安全默认的效果，以后有空再写。