【基础安全】堡垒机的自动化功能实践3

上一章节，对业务功能进行了概要说明。

这一章节，将介绍用户申请流程与管理员处理工单流程的选型与设计，其中资源的创建与关联模块又最具挑战性，其具体方案将影响整个项目的实现难易程度与可扩展性。

01

—

堡垒机api说明

对资源的操作均是独立的，如果要实现资源创建与关联，至少需要六或七个接口，但是在整个系统服务中api数量会变得更多且繁杂。

02

—

方案一：顺序执行方案

使用传统即完全按照顺序执行方案，实现方式很暴力很简单。接口之间没有直接调用的关系，比如创建资源步骤只需要向关联资源步骤发送请求，但两者之间都不关心对方的状态。

此方案存在以下问题：

1）编写复杂，任何一个独立的步骤都需要调用几个接口，调试与编写变得复杂化；

2）拓展性差，如果需要更新某个步骤中的某一个子操作，则需要与同步骤的接口一起调试；

3）同步性难实现，接口之间若用同步实现，难以保证可用性；

4）子操作过于粗，比如创建账号失败，如果想再次创建账号，则需要重新走一遍创建资源的流程。

03

—

方案二：IPC（进程通信）方案

借鉴Nginx官方发布的微服务方案，在实际应用中，通过订阅、推送机制进行进程通信（Inter-Process Communication），便可实现复杂的业务场景。

从上图可以看出：

1）业务逻辑之间，通过推送与订阅的机制来进行消息沟通，一对多，还是一对一，只依赖具体的业务场景；

2）由于划分了众多子步骤，可以允许多语言开发，极大的提高了协作效率

3）子操作更新，仅只需要更新此子操作，而不会影响其他模块；

4）添加新接口，只需要添加一个订阅，消息的推送方完全不需要关心消费者；

5）既有同步响应，又有异步通信。

04

—

实际流程设计方案

通过对以上两种方案的介绍，基于实际业务需求与场景，方案二更加适宜。关于前端页面的向导模式申请验证，比如人员、资产等只需在页面中调用相应接口、添加审核步骤，故在此不做详细介绍。用户申请流程方案：

管理员在接收到用户的申请后，若申请的工单不合规、不能分配申请的资源等情况，需要做打回处理并告知申请人，该部分仅涉及一个接口比较简单。比较复杂、核心的为管理员处理合理申请的流程，其设计思路为：

1）用户提交申请（调用相应的api），api将推送消息到exchange，相应的consumer将消费消息（向每一个管理员发送邮件）；

2）管理员点击相应的链接（调用审核通过api），api发送相应的消息到exchange，每一个消费者调用相应的api，资源创建成功后，会发送相应的消息到exchange。

具体流程为：

该方案实现了不通层级之间通信完全通过推动/订阅方式，每个操作均独立且无需统一框架与编码语言，子操作的更新、修改、维护都非常简单。

如果有更好的思路，不防交流。

下一章节将介绍流程实现中的核心问题与架构优化。