引言
在《安全建设的任务》一文提到了安全建设的一个很重要的任务是资产管理，但是在和很多客户沟通的过程中发现，资产管理很难做。那为什么资产管理难做呢？本文主要分析这块内容，并提出一些参考做法。
资产管理的一些术语：
配置管理数据库(CMDB)：Configuration Management Database
它是一种包含每一个配置项全部关联细节以及配置项之间重要关联细节的数据库
配置项(CI)：Configuration Item
配置项信息覆盖了企业网络中的应用、操作系统、补丁、硬件设备、生命周期成本以及用户链接
配置项分类：Configuration item category
配置项所属分类：如数据库，主机
一、资产管理的范围广
随着计算机的发展，资产管理的范围一直在发生变化，目前大多数情况下谈的资产管理是泛IT资产，不是传统意义上的我有多少台设备等。泛资产是指对组织有一定价值的软硬件信息。包括传统的服务器、IP地址、系统进程、业务进程等；也包括如APP、公众号、数字凭证、品牌、人员（如员工邮箱地址）、知识产权、组织信誉，社交媒体、微信公众号、微博等；还包括企业的安全策略、运维策略、业务的逻辑漏洞等；同时也包括弱密码、安全补丁、版本升级等；还包括软硬件的采购，维保时间，许可证信息等。
从内容上看，凡是有价值的信息都可以往上靠。可以说资产管理是个筐，啥都可以可以往里装。为什么会有这么多的维度呢？是因为不同的人从不同的视角关注的点是不一样的：
财务视角：关注资产的经济价值、状态、软件许可期、硬件质保期等。
桌面管理视角：关注软件许可、硬件配置、系统运行正常、对外接口、防病毒安装等。
IT运维视角：关注业务连续性、稳定性、扩展性、配置和变更管理等。
安全视角：关注资产风险，资产漏洞、资产进程、资产告警等。
这种情况下，在建设资产管理的时候就无从下手。那这个时候我们应该怎样做呢？
可以参考《安全建设的任务》一文中提到的目标和决策：
根据公司对资产管理的诉求，确定合理的目标；
确定合理的资产管理范围；
确定资产管理的类别和属性；
设计资产管理的存储模型。
资产管理建设目标，有的地方也叫消费场景，每个企业都需要梳理出自己真正需要的场景，并且这种梳理应该是基于企业的日常运维工作，以及下一步运维提升的目标来制定，比如：
自动化运维操作：新服务和应用的自动化发布，需要知道当前可用的基础资源有哪些；
IT环境监控和告警：针对某台服务器性能告警，需要判断此服务器所属业务和集群；
资产管理和展示：将企业的IT资产分类展示和查询。
资产管理的几个原则：
“精而不多”：如果我们将大量的配置项或属性纳入到CMDB中，那么将存在大量信息需要进行维护，这无疑增加了成本。反之，如果属性过少，维护工作虽然减轻了，但是CMDB的有效性就大大降低了。因此，“精而不多”就是我们的平衡点，这个‘精’主要体现在对企业有实际意义。
手动和自动结合：手工维护的资产尽量选择自动化做不了的对象，比如资产的名称、资产负责人、资产的关系；企业的业务属性、部署架构等。其他的比如资产的软硬件信息等可以通过自动化的工具去做。
资产管理常用大分类：
分设备、应用、网络、数据和用户；
分有形资产和无形资产；
分内网资产和公网资产等。
CIS Control 对于资产管理有更具体的表述可以参考，它主要集中在硬件资产和软件资产的表述。
对于硬件资产有8个方面的要求：
要有主动发现资产的工具；
有被动发现资产的工具；
通过DHCP进行更新资产信息；
维护资产的目录信息；
维护资产的信息数据；
管理未授权资产；
使用访问控制，比如802.1X的标准接入；
使用证书机制来验证硬件。
对于软件资产相关的内容有10项要求：
保证授权软件；
保证软件有厂商进行维护；
使用软件资产管理工具；
跟踪软件资产信息；
关联软件和硬件资产；
发现未授权软件；
使用应用白名单；
使用加载库白名单；
使用白名单脚本；
隔离高危险应用。
关于授权软件这个事情，其实已经出了很多安全事件案例，比如putty留后门事件，很多盗版软件被植入了木马，引发安全事故，但是盗版软件的使用仍然很常见，很多组织也没做到很有效的管理起来。比如Windows XP和Windows 7等，就算爆出0Day，微软一般也不会支持了。
二、资产的关系复杂
资产管理中的每个资产都不是孤立的，它需要和其它资产产生千丝万缕的关系。随着云技术和微服务的发展，更加加剧了这种关系的复杂性，所以如何梳理这些关系就是一个非常重要的难点。
资产中的关系主要分为构成、连接、需要：
构成：从逻辑层面或物理层面，一个或多个CI构成另一个CI，称为构成，相当于指向父节点，构成是关系的第一法则，构成是单向关系。
连接：连接是一种物理上的硬连接，表示一个CI与另一个CI物理上的连接，连接是关系的第二法则，连接是双向关系。
需要：当一个CI的运行，依赖于另一个CI正常运行时，称为需要，需要是关系的第三法则，需要是单向关系。
只有当资产关系梳理清楚后，才能知道一个故障或者一个问题对业务有什么影响，比如：一个服务器如果停机了，有交换机硬件故障需要更换等，需要快速查出影响了哪些业务系统，并通知相应的负责人。
资产的关系主要有以下几类：
机房-机柜-设备的关系；
交换机-设备关系；
设备-业务关系；
集群-应用关系；
设备-存储关系；
业务-子系统-模块关系；
业务从请求到最终数据库中间的访问关系等等。
关系的维护分为手动维护和自动维护：
像机房-机柜-设备、业务-应用等的这些维护只能通过手动维护。在建设初期就要把关系梳理起来，在后续变更的过程中不停的维护。
像交换机-设备关系等信息，这些信息可以通过程序自动维护，可以通snmp、ssh等协议，去采集分析交换机的接口信息，可以确认维护这些关系。随着SDN的发展，API接口也非常成熟了。这些都是自动维护关系的方式。
三、资产的动态性
在IT建设的早期，由于资产数量有限，网络边界清晰，仅在DMZ区对外开放Web、邮件服务等少量服务，在相对简单的环境里，管理比较容易，用excel等就可以管理的很好。
但随着业务复杂性的增加，以及云计算和容器的发展，使组织的信息资产日益庞大，分布也不仅仅局限在自己的机房、办公场所内，加上早期缺乏规范化的资产管理手段、责任人的变化等等，也让全面了解资产成为一件非常困难的事情。
由于业务需求的不停变化，当今业务的变更比以往变更加频繁，这也导致了资产信息的不断变化。很多企业为了适应市场的变化，几乎每周都有版本的升级、上线和变更。在这种情况下，更要关注资产准确性、时效性。
很多单位的安全、业务、运维部门相互独立，资产管理工作需要协调多部门通力合作，很容易造成出力不讨好、做得好难显业绩、做得不好容易背锅等现象，属苦活、累活之列，所以长期以来这项工作做的并不是很好。
随着系统和运维工具的使用，可能莫名其妙的增加了一个端口，增加了一些dns访问等。安全意识不强的员工可能增加了未知设备的网络接入，使用盗版软件可能留有后门，业务系统系统不知道什么时候多了一个请求路径等等。
由于文档的管理模式等问题，会导致文档满天飞，这部分文档中可能存在员工信息、项目信息等敏感信息。
总之，动态性是现代资产的一个非常重要的属性，我们需要改变思路来对动态的资产进行管理。现在的资产管理就像冰山模型，我们看到的管理的只是暴露在冰面以上的信息。而对冰面之下的各种资产的发现，则是资产安全管理的重大挑战。
动态资产管理对内可以从以下几个方面入手：
主动获取：根据已知的IP地址规划，综合运用多种手段，全面、快速、准确的发现被扫描网络中的存活主机，准确识别其属性，包括主机名称、设备类型、端口情况、操作系统以及开放的服务等信息。
被动获取：被动获取有两种方式，一种是流量，可以通过流量获取到活跃的资产信息，通过DPI（深度包检测）技术实现OSI模型中链路、网络、传输、应用层的流量分析，识别OSI 2~7层协议。可识别资产信息包括：IP、端口、协议、域名、证书等信息。另一种方式是日志分析，通过日志分析可以获取日志中发现的IP、端口、服务等信息，尤其是防火墙日志中包含了大量的资产信息。
Agent获取：通过安装agent获取主机信息。通过Agent可以及时获取非常多的资产信息，包括硬件信息、进程信息、端口信息、服务信息、补丁信息、账号信息、安装的软件信息、系统的文件信息等。
对外的资产可以从以下几个方面入手：
域名解析：最常见的互联网资产收集手段，通过DNS服务器或字典式解析探测，以获取开放的子域名和解析情况。
备案信息：备案数据中包含了组织会使用到的域名或IP，一般和域名解析结合使用，能更加全面的发现主域名和解析情况。
Whois数据：Whois数据通过域名的归属关联，查询相关的其他域名，以便进一步发现资产，同样是和域名解析情报配合使用。
空间测绘平台：通过空间测绘手段获取到资产信息，现在有很多网络空间测绘厂商可以提供数据。
搜索引擎：通过搜索引擎检索获取到的网站类资产信息，包含google、百度等检索结果。
移动应用、小程序、公众号：通过已知APP或小程序，可以获取其中访问的URL信息，这部分URL中往往含有和内部通讯的API地址，但同样也可以获得第三方API地址等信息。
四、业务的复杂性
随着行业IT应用的业务复杂度提升、数据级日渐庞大、应用面越来越广、并发压力也越来越高。为了应对这样的情况，分布式系统的解决方案随之而出，成为目前主流架构模式。
目前，大部分大型WEB系统发展趋向，都采用类似互联网基于业务服务化并行架构设计模式，对业务进行深入拆分规划、服务化，微服务、SOA 等服务架构模式正在被大规模的使用。业务系统的服务部署，也逐步采用各种主流的技术方案，例如虚拟化、Docker、云托管等。
分布式系统架构的采用、业务服务化和微服务的采用，对于大型WEB系统来说，可降低系统开发整体难度、提升系统开发迭代周期和效率等，也可以引入不同的技术栈协同开发，不同开发团队同时协作开发。
但这时也产生了一个问题，就是业务系统的服务拆分的颗粒越细、越独立，例如像现在很多大型平台搭建各种业务中台、技术中台等，反而有时会使系统架构设计的复杂度变的更高，采用的技术底层处理框架会更复杂。框架越复杂对资产管理运维的要求就越高。
资产是为业务服务的，所以在做资产管理的时候一定要考虑到业务视角。但是在很多传统管理的时候，会存在业务和资产两条线，这种管理可能相对简单，但也面临着很多的问题，包括沟通和管理不便等。
所以资产管理要以应用为中心，从业务角度出发，从而统一地管理企业IT架构中设备的配置信息。比如一个典型的互联网应用以层级的方式逐级展开各层资源：
应用本身可能是不同群集环境的：生产群集、测试群集、预发布群集等；也可能是分不同区域群集的：华东区域、华南区域、西北区域等；
每个群集内部又分为不同的模块：前端web服务模块、中间件模块、数据库模块、其他组件模块等；
每个模块内部可能是具体的虚拟机、物理服务器、容器、公有云、私有云、混合云等基础资源，以及中间件应用、数据库应用、web应用、业务本身的应用进程和服务等上层业务逻辑资源；
每个资源对象本身都有自己的配置信息，对象与对象之间有着各种各样的关联关系。
从业务的角度梳理完成后，资产管理需要的模型（CI）、属性（CI项）、关联关系等就梳理清楚了。
五、资产信息的零散
资产管理是很多系统管理中最基础的内容，所以很多系统中都或多或少地存储一些对自身系统有用的资产信息。每个系统都会从自身的视角看待资产，比如财务系统从资产价值、采购、使用、报废等维度看待资产；运维人员从资产的可用性、资产的关系等看待资产；终端管理从资产的软硬件属性看待资产；日志分析从资产日志的采集角度看待资产等等。这就会导致资产信息的割裂，没有一个地方可以从整体上看到资产的全貌。同时从管理角度看很多部门是相对独立的，这样就更难从一个全局的视角看待资产。
如何有效地组织资产是个非常重要的问题。如何把这些割裂的资产信息进行整合，从一个更完整的视角看待资产是个挑战。当资产是一个整体的时候，对资产的管理、使用、加工、处理、消费等都有非常大的好处。从宏观上看到资产的全貌，从微观上可以从一个入口看到资产的所有信息。这样可以极大地提高管理的效率。
所以，有条件的话，可以规划一个整体的资产管理平台，把其他系统的资产信息统一收集整合加工，其他系统需要资产信息的时候可以消费。这样可以了解资产的全貌。
六、资产的使用效能
在国内，很多客户依然存在重视硬件投入而轻视软件和服务的投入的问题。主要是因为硬件能看得见摸得着。但投入这么多的硬件是否有必要？这个问题很多客户不一定能说得清楚。过多的资产会带来管理成本和使用成本的增加。
在资产管理中经常会出现资源不够的问题。比如很多业务部门提出来资源不够，但这个时候很难判断资产是否是真的不够。比如资产的利用情况、使用情况等信息不确定。如何评价每个资产的利用效能，也是一个非常重要的问题。
系统的使用情况包括：cpu利用情况、内存利用情况、磁盘利用情况、集群使用效果、网络的并发情况、业务的增长预期等。所以需要跟踪每个资产的使用效果，来确定对资产的投入价值。不过现代计算机已经非常快了，参见《计算机超速进化，你准备好了吗》，大多数情况下资源的利用都是不充分的。做好这块可以支撑IT投入规划、业务使用的成本核算，实现IT资源优化利用，使IT成本与效益达到一个好的平衡。
6.1资源分配方法和原则
对存储资源采用分解法估计，对数据库服务器资源采用TPC-C值估算法，对Web服务器资源采用SPECweb2005估算法，对应用服务器采用SPECjbb2005估算法。
资源分配的基本方法是：首先了解信息系统的非功能性需求，初步估计对各类型服务器（数据库服务器、应用服务器、Web服务器、接口服务器和其他服务器）的总体资源需求，再根据需求冗余、安全等方面要求，确定各类型服务器所需物理服务器数量，基本原则如下：
单台服务器能提供足够处理能力的，不再分解为多台物理服务器。
数据库服务器采用双节点冗余（如Oracle RAC）时，处理容量一般按增长50%计算。
应用服务器采用多个逻辑(物理)节点组成集群时，4个节点以下（含4个）的集群，总体处理能力一般按各节点处理能力总和的60%计算；4个节点以上的集群，总体处理能力一般按各节点处理能力总和的50%计算。
web服务器采用多个逻辑(物理)节点组成集群时，4个节点以下（含4个）的集群，总体处理能力一般按各节点处理能力总和的70%计算；4个节点以上的集群，总体处理能力一般按各节点处理能力总和的60%计算。
6.2服务器资源估算方法
6.2.1数据库服务器TPC-C估算法
适用范围：适用于对数据库服务器（应用服务器、Web服务器可参考）所需服务器的CPU能力进行估算。根据估算出的TPC-C值选择合适的服务器和服务器配置。
原理介绍：该估算法是通过计算应用系统峰值每分钟需要处理的业务交易数，再综合考虑业务交易的复杂程度、未来业务交易数量的增长和CPU处理余量等因素，通过公式计算得出一个估算值，以此来评估需要服务器必须达到的TPC-C值。
6.2.2Web服务器SPECweb2005估算法
适用范围：适用于为支持满足特定吞吐量和客户请求响应速率要求的WEB服务器的性能进行估算。
原理介绍：Web服务器通常需要衡量它可以支持满足特定吞吐量和客户请求响应速率要求的WEB服务器的最大并发连接数量，而SPECweb2005是由标准性能评估组织（SPEC）专门开发的的Web服务器基准测试。服务器厂商通常会提供每种型号服务器的SPECweb2005值。使用本方法估算不考虑网络因素，假设客户端和服务器位于同一局域网中，网络传输时间可以忽略。
6.2.3应用服务器SPECjbb2005估算法
使用范围：适用于估算Java类应用服务器所需达到的服务器性能。
原理解释：SPECjbb2005是评估服务器端Java性能的SPEC测试工具。SPECjbb2005通过模拟三层C/S系统(主要是中间层)来评估服务器端Java的性能。该测试软件运行JVM(Java虚拟机)、JIT (Just-In-Time)编译器、碎片收集、线程以及操作系统的其他任务，它同时也测量CPU、Cache、内存和 SMP的性能。
服务器上运行基于J2EE的中间应用软件平台，可以将其应用处理能力量化为Java处理能力性能值SPECjbb2005，同时充分考虑系统的冗余处理能力以及系统资源分配情况，即可估算出服务器的处理能力性能值。
6.2.4数据库服务器内存估算法
适用范围：适用于估算数据库服务器（应用服务器、Web服务器可参考）所需的内存。
原理介绍：数据库服务器相对其他服务器来说，因为涉及大量的数据处理，需要把数据载入内存，以加快处理速度，所以需要更多的内存。对于内存的估算一般有下述两种方法，建议采用下述两种方法分别估算出所需的内存，取其中最大的数值。
计算方法：
方法一：
根据标准化设计，将数据库内存容量（单位为G）和CPU的核心的数量的比例按照4:1配置，一个CPU的核心对应4G内存。例如服务器配置两个4核CPU则建议配置32G内存。
方法二：
原理介绍：数据库服务器的内存主要包括：操作系统占用内存、数据库系统占用内存、数据库并发网络连接占用内存等。按照经验，Windows平台内存占用率不超过55%、Unix（或Linux）平台内存占用率不超过80%时，不会影响系统的性能。
6.3存储资源估算方法
申请存储资源时，应根据下述方法估算所需存储资源的需求，存储需求主要包括数据库存储需求、普通文件存储需求和系统运行存储需求三类。存储的主要依据是根据数据量计算，先计算每条数据的存储空间，再确定每天大概多少条数据；然后根据存储的天数计算需要的存储量，最后乘以一个安全系数。
总结
通过以上分析可以得知，做好资产管理是非常难的，但不能因为很难就不去做。希望能通过以上分析，对做好资产管理起到抛砖引玉的作用。
相关分享：
