CMDB项目总结

　　在公司多位同事的共同努力下，终于把CMDB这个项目给完结了。下面我就来总结一下，在这个项目中的一些坑和这个项目的亮点吧！

　　首先，我们来聊一下，我们当初为什么要开发这个项目吧，我们公司原来对资产的维护，依赖的是Excel表，随着公司业绩蒸蒸日上，资产的日益壮大，领导和同事们都察觉到Excel表已经捉襟见肘了。特别是在资产变更时、信息交换时，都很难保证Excel表数据的准确性。并且，每次在盘存时，都要花费大量的人力、时间等，这对于一个公司来说，是非常不好的。在这个实际情况下，领导当机立断，决定自己开发一个自动采集资产的工具，经过同事们多次开会讨论，我们的目标：自动采集数据汇报，保存变更记录，最终目标是实现运维自动化。

　　接下来，我来说一下我们这项目的架构吧！

　　我们这个CMDB共分为三部分：

• 资产采集（负责对内网里所有机器通过命令，获取相关信息）
• API（接收数据保存入库，对外提供数据接口）
• 后台管理（运维管理人员通过后台管理实现对数据的增、删、改、查）

　　好了，架构就是这样，下面我们来聊一下里面都有哪些亮点吧！

　　亮点一：在资产采集里面，我们支持当下主流的三种模式，分别是：1、Agent；2、SSH类，如：paramiko；3：saltstack。通过配置文件选择这里面的任意一种，程序会自动执行对应的方式进行数据采集。这里我们开发了可插拔式插件，我们主要参考了Django的中间件，利用配置文件，通过Python的反射，利用的是 importlib模块来实现对字符串自省，而后并执行对应方法完成该项信息的采集。完成所有的信息采集之后，通过API接口将数据保存入库。

　　亮点二：在API接口里面，考虑到数据的安全性，刚开始一直是我们的一大难题。后来，在我有一次看Tornado源码的时候，当我看到它对Cookie加密的时候，受到了启发。后来，我跟领导和同事一起探讨了一下，最终决定就用此招。刚开始，我们用静态的秘钥进行MD5加密，后来发现用静态的安全性不高，容易被黑客截获，我们就想什么东西能够动态起来呢！就在我们绞尽脑汁的时候，看看桌上的小时钟滴答滴答一秒一秒的走着，突然灵机一动，可以通过秘钥+当前时间一块MD5加密，这样令牌就动态起来了。可是，在API端怎么验证呢，你传输的速度再快，时间戳肯定不可能完全一样啊！后来，我们又进行了改进，我们在发送加密后的字符串后面拼接上了客户端的时间戳一块发送至API端，API端接收到数据后，首先进行字符串分割，得到客户端的时间戳，拿着客户端的时间戳与秘钥进行MD5加密，得到MD5值与客户端发来的进行校验，完成用户的合法性校验。但在我们测试的时候，如果黑客截获了你的验证码时，就不安全了。于是，经过我们这个强大的团队，共同努力下，终于又攻破了这道难关，我们设置了三道关卡，欢迎君来挑战，是哪三道关卡呢，待我来慢慢道来。

　　验证第一关：

　　判断服务端的实时时间与客户端发来的时间差是否大于咱默认的时间差，如果大于的话，直接就pass掉。

　　验证第二关：

　　用用户发过来的时间戳和本地的密钥，跟客户端的方式一样进行MD5加密处理。得到的结果与客户端发过来的MD5值进行校验，如果校验未通过，说明黑客有可能修改时间了。导致过了第一关，但，由于修改了时间戳，MD5的值肯定就匹配不上了，直接就pass掉了。

　　验证第三关：

　　为了防止在设定时间里，密钥被黑客截获，进行二次访问，我们会创建一个字典，第一次访问时，会被记录在字典里，字典的结构为：客户端传过来的值为字典的key，value为客户端传过来的时间戳加上咱们设定的超时时间。判断客户端提交的值，在字典里是否有这样一个key与之匹配，如果条件成立，说明同一个加密结果，已经来过一次了，验证不通过。

　　以上三关都通过了，就可以开始对客户端的MD5值与服务端的MD5值进行校验了，没通过的话，就认证失败了。为了节省资源，在第二关的时候，会对字典进行维护，循环记录字典，判断超时的键值对，会进行删除，节省资源，避免资源浪费。