管理实践.原创 | 金融企业CMDB建设实践

一、前言

      CMDB是一个既熟悉又陌生的概念，作为技术管理者一定听说过CMDB，但对CMDB的实际应用不一定有深刻了解。笔者在CMDB建设和使用方面具有多年的实践经验，本文采用通俗易懂的方式进行讲解，场景化的应用实践介绍，希望能给大家在建设和优化CMDB时提供参考。

      本公众号(信息安全运营)发表的内容不包含企业秘密，仅代表个人言论，仅供各位参考。

二、CMDB是什么 

      上图是某百科对CMDB的定义，笔者认为存在明显的错误，经过反复思考和结合实践，笔者总结出以下三点内容，是否比某百科更好理解和更准确，由读者进行评价。

      第一、CMDB是一个逻辑数据库，存储和管理需要管理的对象（专业术语叫配置项Configuration Item）和对象（CI）之间的关系。

      第二、CMDB的内容要被使用，能发挥信息的价值。使用者可能是某个业务系统、可能是本人、可能是团队其他成员。

      第三、CMDB必须有流程或机制来更新信息，保证信息的准确性。可以是自动的，也可以是人工的。

      如果文字不好理解，笔者画了一张关系树，这张关系树包含系统台账、硬件台账、软件台账、数字证书台账、人员台账、供应商台账、应急联系人台账、合同台账、机房台账、机柜台账、IP地址台账等等管理对象。这些对象之间是存在关系的，例如应用系统分配多少台服务器、部署多少软件、使用多少张数字证书、等级保护是几级、软件供应商是哪家、是否有维保服务商、维护负责人是谁等等。这些全部要存储在CMDB中进行管理，对外提供服务接口用于数据查询和数据更新。

      如果关系树有点抽象，笔者给大家展示数据库中落地实施的数据表和关联。数据表就是台账，例如资产台账包括资产编号、品牌型号、序列号、硬件配置、操作系统、IP、到货日期、启用日期、运行状态等自有属性，机房、机柜、应用系统、部署软件、数字证书、主岗、备岗、供应商等外部属性通过关联进行建立。

三、为什么要建设CMDB

      建设CMDB是外部监管机构的要求，也是内部团队协同工作的基础。

      证监会2013年发布的《证券期货业信息系统运维管理规范》(现行有效)明确要求证券期货机构应建立配置库，对交易业务系统的服务器、存储、网络、安全设备、操作系统、应用软件、数据库等进行管理。

      金融企业随着规模的不断增长，信息系统数量和技术人员数量也不断增加，原有的电子表格台账存在无法关联、更新不及时、无变更记录、不支持高并发访问等短板，已无法满足团队高效协同工作的要求。很多工作需要应用系统管理员、存储系统管理员、基础架构管理员、网络安全管理员共同完成，CMDB就是团队高效协同工作的专家系统。

四、如何选择CMDB

      目前除了自研CMDB外，采购商业软件和使用开源软件都是较好的选择。对于经济实力雄厚和对CMDB有着较高要求的金融企业，可以优先考虑商业软件；对于系统建设比较谨慎和技术人员爱好研究新技术的金融企业，可以优先考虑开源软件；对于无法投入数十万以上采购商业软件，又无技术人员研究开源软件，可以优先考虑外包方式（开源软件＋技术服务）。

五、如何建设CMDB

      使用开源软件是建设CMDB的一种方式，笔者使用一台较低配置（4核8G内存60G硬盘）的虚拟机就完成CMDB的部署，部署时间小于2小时，内存增加至12G可作为办公系统支持30位人员的并发访问，增加服务器可实现高可用架构。

      CMDBuild软件是由意大利团队维护的开源项目，初始版本发布于2006年，每年保持一次以上版本迭代。目前最新版本是3.4.1，发布于2022年9月30日，支持私有化部署，已支持全球32种操作语言，是被认可度较高的开源CMDB软件。在官方网站有应用软件、技术手册和说明手册等提供下载。

六、如何使用CMDB

      CMDB的使用一定要场景化，实实在在地将CMDB用起来，发挥CMDB的价值。本次介绍3个场景，笔者实际已使用包括应用管理、运维管理、项目管理、基础架构管理、安全管理、资产管理、综合管理、供应商管理等的20多个场景。

1、资产台账管理

      CMDB的发展源于资产管理，目前已涵盖技术管理的方方面面，具体管理内容取决于管理者的管理需求，本次介绍的第一场景从资产管理开始。

      资产管理的基础功能是实现资产台账的线上化，将原来保存于电子表格的台账导入到系统中进行管理，这是高级资产管理的基础。在电子表格的时代，资产台账由资产管理员进行独立管理，记录在一张资产台账里，例如服务器功能这项是他无法管理好的，因为决定服务器功能的不是硬件，也不是操作系统，是应用软件，应用软件由应用系统管理员进行部署和管理的。使用CMDB能很好解决上述问题，将服务器信息的管理职责进行拆分，各自负责职责范围内的内容，真正实现团队的高效协同。

      资产管理员对服务器的资产编号、品牌型号、序列号、硬件配置、到货日期、启用日期、所在机房机柜位置、运行状态在“卡片”内进行维护，不涉及使用功能，详见以上截图。

      主岗备岗可同时操作，数据修改立刻生效，可以避免主岗和备岗在信息方面存在差异。也能有效规避将不合适的责任分配给不具备权限的人员进行承担，更好地实现权责对等。

      应用系统管理员专注于服务器的使用功能信息，动态形成“关系”，详见以上截图。

      例如某系统被分配了服务器，应用系统管理员建立一下“系统名称”与“所分配的服务器”的关系。应用系统管理员部署了应用软件，填写软件部署信息，建立一下“应用软件”与“运行的服务器”的关系。应用系统管理员部署了数字证书，填写数字证书信息，建立一下“数字证书”与“运行的服务器”的关系。网络安全管理员发现了一个安全漏洞，填写漏洞管理信息，建立一下“漏洞信息”与“运行的服务器”的关系。

      通过截图能清楚了解到此服务器分配给2个应用系统使用，使用一张数字证书，有效期到2023年3月28日，曾经出现2个系统漏洞，曾经出现1个技术问题，部署2套应用软件。这些都是通过关联的方式自动形成的，建立关系时自动添加，关系解除时自动消失。

      特别说明：金融企业不会在一台服务器上同时运行交易类和非交易类的应用软件，也不会将交易类和非交易类的服务器放置在同一个DMZ中，分层分区是基本的安全管理原则，上述举例是希望向读者展示CMDB的功能。

      CMDB系统的审计功能是非常重要的，在一定程度上保障了数据的准确性和更新的及时性，在“历史”中展示，详见以上截图。

      审计记录可以详细记载数据的全生命周期的变化，什么时候、由谁进行登记或修改、修改的最新内容都全部进行记录，这些记录是永久保存的，而且查看特别方便。

      如果与部门的管理制度进行结合，要求系统管理员在更新CMDB后到OA流程中进行反馈，系统管理员就没有了偷懒的空间，因为审计信息将如实记录他的相关操作(操作内容和操作时点)。

      “误改”是人工更新数据所绕不过的话题，如果有上述强大的审计功能，发现信息被误改是可以很容易纠正的，因为历史数据都在，可以实现秒级找回。如果是原来的电子表格台账，历史数据已被覆盖，修改时间也不知道，能否找回都是一个问题。

      场景小结：基于CMDB，资产管理的职责被正确地进行拆分，资产管理员负责硬件管理，应用系统管理员负责功能管理，各自负责维护好职责范围内的内容，确保数据正确和更新及时。在管理实践中，需要规章制度明确更新CMDB的职责要求，在处理OA变更流程时如遇到资产信息变化需反馈更新CMDB的大致内容，确保CMDB资产数据得到更新，准确的CMDB资产数据才有价值，才能支撑技术管理工作。

2、应用系统管理

      “应用系统”是技术管理的工作重点，技术部门的多数岗位都是围绕 “应用系统”开展工作的，现在介绍“应用系统管理”场景的使用，看看基于CMDB如何支撑团队进行高效协同工作。

       如以上截图所示，通过“卡片+关系”的方式实现对应用系统的360度画像，真正全面了解应用系统才能管理好应用系统。

       作为应用系统管理员，是否真的了解所管理的应用系统？如果说主岗了解，备岗是否同样了解？我们希望在应用系统信息方面，主岗和备岗能达到一致的水平。

       “卡片”内的信息由应用系统管理员负责维护，应用系统管理员主岗也未必熟悉相关信息，例如无法给出系统“上线日期”的正确日期，原因是前任维护人员的交接资料里没有系统上线日期，借助维护“卡片”信息的机会可以对系统信息进行补正，是一劳永逸的工作。

        “关系”内的信息由相关管理员负责维护，系统定级信息由安全管理员关联过来，存储信息由存储管理员关联过来，维保信息由合同管理员关联过来，漏洞信息由安全管理员关联过来，数字证书信息由应用管理员关联过来，问题信息由问题登记者关联过来，主岗备岗由负责主管指定并关联过来等等，关系解除时自动消失。

        “附件”是每条信息都具备的属性，可以根据需要进行管理，例如在应用系统里可以上传“系统验收报告”、“系统功能测试报告”、“系统用户手册”等附件，需要时可以快速进行阅读和下载。

        基于网络带宽和用户体验的考虑，笔者一般设置单个附件大小上限为30M，数量不限，基本能满足使用要求。

      场景小结：通过使用CMDB，技术部门人员能比以前更加了解业务系统，知道业务系统的基础架构信息、系统管理员信息、安全信息、维保信息、供应商信息、联系人信息等等，当然这些信息是所有人员一起贡献、知晓和维护的，真实而且及时的，所有各岗位的技术人员能形成合力，消除潜在的风险隐患，共同保障应用系统的安全高效运行。

3、供应商管理

      金融企业一般不会建设独立的供应商管理系统，或采购OA系统中的供应商管理模块，使用CMDB进行供应商管理是比较合适的解决方案。

        “关系”内的信息全部通过关联自动生成，可以动态展示与该供应商签订的合同信息、该供应商为本企业提供的应用系统清单、目前提供哪些系统维保、业务联系人、技术联系人、历年的考核评价信息等等。

      场景小结：供应商是技术部门的合作伙伴，特别在应用系统出现异常时，技术人员必须立刻联系到供应商的技术联系人，如果技术人员把供应商公司和联系人信息集中维护，可以避免因联系不到人员而耽误异常情况的快速处理。

七、CMDB建设基础

       建设CMDB是将原来分散在各个人员手中的电子表格和附件进行集中化、在线化管理，建设基础是信息的标准化和规范化，以下是一些举例和处理方法。

1、名称不统一

八、CMDB建设难点

      以上截图来自《CMDB分步构建指南》书籍，“世人追求短期效应者众、看重长期发展者寡。打基础的事情，往往最难，在中国尤其如此。”在一定程度上体现CMDB建设的难度特别大。

      如果是采购商业软件来建设CMDB，建议把项目按照“一把手”工程进行处理，最好以管理咨询项目进行切入，没有公司领导或部门负责人的支持注定会失败。如果是使用开源软件来建设CMDB，以满足资产管理、应用系统管理等场景化使用需求，可以立刻开始建设，基本没有难度，成功的概率很高。

九、补充说明

      此款CMDB软件具备完善的权限管理功能，基于用户组进行设置权限，可以定义不同的导航菜单(如上图所示)，可以对不同的数据表定义添加、克隆、修改、删除、打印、导入、导出、附件、关系查看、历史记录查看的权限，可以在用户组之间进行切换。

3、强大的关联能力

      例如知道一个IP地址，可以关联出部署的软件、应用系统名称、系统管理员姓名、系统管理员手机号码、实体服务器、供应商公司、供应商技术人员姓名、技术人员手机号码等等，只需要在“关系”里不断打开卡片即可。

4、准确的数据底座

      经过一段时间的运行，CMDB中存储着准确的各种数据，这些数据可以给技术管理的很多系统使用，包括CMDB系统自身和其他各类业务系统，成为了技术管理的数据底座。

      例如系统管理员前期已经维护了数字证书信息，笔者通过定制开发，读取数据库中的证书到期日期、证书名称、应用系统名称(关联获得)、系统管理员主岗和备岗的姓名(关联获得)、主岗和备岗的手机号码、电子邮箱(关联获得)，结合当天日期，计算出剩余有效期天数，在剩余有效期的90天、30天、15天、7天和3天向主岗和备岗发送通知电子邮件，同时抄送运维主管和笔者，向主岗和备岗发送手机提醒短信。

      可以使用CMDB数据的包括监控系统、安全管理系统、流程管理系统、数据报送系统等等，详见各软件厂家的解决方案文档。 

5、个人安全实验室

     本文章展示的所有图片均来自笔者的个人安全实验室，由笔者根据分享的需要进行构建，并非金融企业信息， 不涉及企业秘密。

6、CMDB是个筐

--文章结束--

注：作者陈建茂(微信号shenzhenmao)，十余年金融信息安全管理经验。