目录：

篇一：浅谈root账号安全管理

篇二：供应商及人员安全管理

篇三：职业欠钱理解的安全运营

篇四：测试环境安全管理漫谈

篇五：流量层检测的未来何去何从？

篇六：安全资产管理

篇七：操作系统补丁管理与代码扫描工具探讨

篇八：矛与盾，攻与防杂谈集锦

篇九：如何进行有效的安全规划与汇报？

篇十：小议数据安全场景应对之道

篇十一：众说纷纭聊安全弹性与韧性

1 安全资产管理的难点分析

CMDB本身是个基础资源平台，不应该是安全团队的工作，但安全最关心资产的问题，而且所有的防御措施和策略其实都是围绕资产来展开的，不搞这个还真不行。

在企业安全实践群，大家讨论激烈：有说“安全的发现探测能力可以对 CMDB补充。其实不管是不是安全的活，如果运维或者IT不想做这事，安全也就只能主导了，CMDB 对安全来说是强需求。”也有“我们目前使用的一些安全运营平台其实都有各自的资产管理模块，但实际用起来很麻烦，视野太小，不符合企业的实际情况。被逼无奈之下，目前正在自己打算开发一套以“安全”为视角的资产管理模块，重新定义资产的属性和管理关系。”

最终意见是CMDB一般安全会有自己的数据库，谁负责谁主导，安全诉求强的情况下需要整理出所有机器和应用，这种需求运维是比较少的。安全的CMDB和运维的CMDB纬度也不太一样。CMDB是运维的资产库，但运维更关注业务线；安全的关注点在于发现“隐秘的角落”，反过来补充CMDB。安全可以通过影子资产发现、无用资产浪费等角度推动运维加强 CMDB 建设。

除此以外，安全资产管理还面临这三个难点：一是资产信息的梳理和收集不好开展，难以保证全面和准确；二是资产之间的关联也是个费劲的事情，较难以“系统”为单位去看待资产的归属，不能较好评价资产属性跟安全策略控制粒度的映射关系；三是在安全日志分析过程中，对资产信息的引用和查询，也比较费劲，缺乏良好的管理工具。

如果说安全防护像是一场守城的战斗，那么安全的 CMDB 就是一张城防图，一是需要了解不同等级资产的部署位置，二是要了解各资产的逻辑关系，三是要了解各资产的安全策略现状，四是要了解各资产之间的关联关系，流量走向，五是对结合上述情况对安全策略做评估，沙盘推演，六是对按照推演或者测试结果，边界设备进行加固，对资产进行漏洞修补。CMDB不全不准，感觉搞的都是局部和底层，没有落实顶层设计的安全防护思想，没有灵魂。

2 如何建设安全的CMDB？

安全对 CMDB 的依赖有好几个阶段，核心是安全水位提升或安全风险是否受制于 CMDB。安全 CMDB 和运维 CMDB 的核心差异是安全对数据全要求比运维高很多，运维一般不关注废弃资产、无用资产，只关注影响业务稳定性的资产，这部分资产会成为安全短板。从零开始建设安全是以公网边界、办公网边界、核心资产为主，这个时候安全人也少，此时没精力建设 CMDB，一般是复用运维的 CMDB 库提升主要的安全水位；之后安全会用资产发现去看有无漏过的边界资产；再往后建设内网安全时，对自建 CMDB 的需求会提升很多，内网中会存在很多废弃资产，这部分资产的安全性是需要安全cover的。

建设 CMDB 区分了几个阶段，最开始都是用 IT 和 SRE 的系统上获取主机，负载映射，域名 location 这样的信息，包括一些机器业务线及负责人的数据，之后慢慢才会开始搞 API，内外网各类接口，和网络联通性划分。这部分其实生产网要比测试和办公网好搞很多。最后才会逐步把安全产品的相关属性接进来，比如 HIDS 扫描主机上的三方依赖版本，数据库或者某些框架信息，WAF 上面发现 API 被攻击次数，或者端上设备特定安全属性。基础 CMDB 非常依赖和其他部门的合作，而且很难有人敢保证手里的数据是全的。

需要注意的是，厂商的资产管理视角，跟内部的运维、研发的资产视角不一样，所以安全来搞资产，更多应该是作为反向验证监测，正向的CMDB、CMS有条件还是要从顶层设计上划分好责任，推动运维、研发来实施，利用国家大型红蓝对抗和搬迁数据中心的机会梳理清楚。

注：实践注意点可以参见从CMDB到SCMDB，安全资产管理的实践探讨。

3 易忽视的五大安全资产

1.分支机构和公有云资产：除了总部和自有资产以外，还要考虑组织分支机构和外部公有云的相关资产，避免在安全运营及外部合规性核查中因自身资产盲区导致不良后果。

2.新型安全资产：还存在着一些不引人注意的资产类型。例如企业公众号、企业微博号等组织市场推广资源。从组织整体安全运营的角度看，这些资源可能存在误用、盗用、使用不规范等问题导致发布了不合适的内容信息。公众信息发布的安全性，也可以作为安全资产管理的一个关注点。

3.存在安全隐患的隐藏资产：除了直观可见的安全资产外，还存在着一些不面向大众用户的隐藏资产。例如开放在公网API接口、网站管理后台等。以API为例，该资源不得不开放在互联网侧，基于用户的分布性又难以限制可接入IP，容易受到API参数篡改、内容篡改、中间人攻击等安全威胁。可通过前端防护设备及鉴权控制保障此类资产的安全性。

4.特权账号：特权账号因其权限较大，比普通账号具有更强的脆弱性。账号作为业务系统人机交互的钥匙，在安全资产管理中容易受到忽视。

5.易被忽视的资产属性：还有一些容易受到忽视，但对业务安全及业务可用性有很大影响的资产属性。例如网站证书的有效期、域名有效期、各类设备维保时间和供应商联系电话等等。

最后，欢迎各位读者畅所欲言，您可以在留言区写下您的想法和建议，我们一起讨论。同时，小编也会在后续的群精彩话题中，尽可能结合您的建议来组织编辑，并会将您的问题向强大的群组织请教解题之法，期望能为您带来最大的帮助。

来源:企业安全建设实践群 | 作者：群友 

本期编辑:进击的兔子

往期精彩群话题

办公安全实践讨论：沙盒的用户体验、终端DLP+虚拟化浏览器+上网行为管理+网络DLP的互联网方案以及数据网关作用

因勒索软件攻击，数据被加密：IT主管和工程师被开除，并要求索赔 21.5 万元

SOC技术架构及运营讨论

更多精彩内容，点击阅读原文！

如何进群？

请见下图：