Question

通常我们把金融数据密码机简称为加密机，其应用场景如图 18-5 所示。

从图 18-5 可以看到，加密机的应用场景非常广泛。由于加密机往往涉及各种核心业务系统交易验证环节，一旦出现可用性问题，影响的可能是全行业务，所以作为加密机管理员，可用性责任会比较重。随着业务种类的变化，有的企业还会引入签名验签服务器以满足业务的需求，这里我们统称为广义上的“加密机”。

图 18-5　金融数据密码机应用场景图

18.5.1　选型

加密机的引入，需要一个选型测试的过程。建议加密机管理员在选型上做好工作，从源头上对加密机厂商、型号进行控制，有利于日后的运维工作。选型标准或要求建议如下：

·对称类应用，首选 A 型加密机（每个企业基于自身使用现状进行选择，这里不做推荐）。

·对非对称类应用，首选 B 型签名服务器。

·如有项目需要与外联单位开展业务合作，而且对方要求指定型号的设备，需提供对方出具的正式文件并经领导审批方可使用。

·如有特殊应用需要使用与此标准不匹配的加密机，需要提供详细的测试对比数据，并经领导审批方可使用。

18.5.2　高可用架构与监控

加密机虽然是安全设备，但日常工作大多是与可用性相关的，可以说基本上就是运维的工作。可用性需要有合理的架构设计和配套的技术来保障。

1.架构

架构可以简单地理解为，设备部署在哪，应用怎么连接。

设置部署位置按业务的重要程度不同而不同，重要业务系统往往同时部署在多数据中心，那配套的加密机也要与之相应。同一个数据中心，加密机要分布在不同楼层、不同网段，如果在同一个楼层，要分开部署在不同的防火区。

应用连接基本分为应用直连、应用连接加密机池 VIP 两种模式；在连接方式上有长连接、短连接之分。对于直连的应用，要求由应用实现负载均衡，即应用探测到某台加密机故障后需要在应用上进行隔离，新的交易不再发往该加密机；对于由负载均衡提供 VIP 的方式，需要在负载均衡上进行应用级探测，即模拟应用向加密机发送报文查看加密机状态，一旦加密机状态返回异常即进行隔离。

有的厂商提供了统一管理平台，相当于代理，即不同的业务系统都连接这个平台，再由这个平台将请求向后端转发处理。建议适当评估，这样的方式虽然方便，但存在风险集中的隐患。

2.监控

对设备的可用性进行监控，一般有 Ping 探测、TCP 端口探测、应用层探测。对于加密机这种特殊设备，建议要深入到应用层进行监测，图 18-6 为某可用性监控软件探测指令截图。

图 18-6　加密机指令探测

除了基于设备的探测外，还需要从网络流量、业务交易量的视角对设备进行监控。比如短连接的业务，在 F5 上看当前连接数应该很少，甚至是 0，某业务上线后发现这个数字变多了，那么估计是有问题的，多半是开发写的代码有问题，比如新建了连接却没有主动释放。再比如，业务都有高峰低谷，可以结合历史交易进行一些上下限阈值设定，对请求数、响应率、响应时间、成功率等进行监控，当有偏离时可以作为辅助判断。当然实际生产上突破阈值可能有其他原因，比如暴雨天气导致某分行 ATM 交易量下降，支付宝切量导致网联交易量下降等。

18.5.3　应用梳理

对于已经在线上运营的业务，如果选型这一关没有把控好，还需要开展全面梳理工作，主要包括设备机架位置、IP、白名单、品牌、版本，还有应用的连接情况（直连、负载均衡）、对应的业务相关的联系人（系统管理员、加密机管理员、开发人员、业务条线对口人员）等。对于不同型号的加密机，还有一些与该品牌相关的特性信息需要单独补充说明。以某品牌加密机为例，补充说明如表 18-3 所示。

表 18-3　某加密机的特性信息说明

再以某品牌签名服务器为例，补充说明如表 18-4 所示。

表 18-4　某签名服务器的特性信息说明

18.5.4　上下线与应急

上线和下线是相对比较基础的工作，需要注意的是加密机管理员和密钥管理员须严格区分。很多业务往往是上线容易下线难，这就需要各种沟通协调工作了，同时还需要配合技术上的监控。比如，某开发组说应用不再连这个加密机了，管理员在下线前还需要确认是否除了监控探测外，真的没有流量再访问该加密机，否则可能会出现可用性事件。下线的设备可能还要走相应的报废流程，一定要对密钥进行销毁。

可用性架构做得好的企业，单台加密机出故障不会使业务受影响。基本的应急操作都是重启，有些时候担心重启过程有影响，可以在 F5 上将设备 Disable 或者机房拔掉网线，重启确认没问题再插上。