运维可从外部连接的服务器时，也需要谨慎处理服务器发来的报告。服务器或软件故障、配置变化、遭受入侵的可能性等因素，都可能导致报告无法充分反映实际状态。

BASTION重视对DMZ中Agent发来的信息进行验证，并限制允许执行的操作范围。本文介绍这一设计思路及运维中的核查要点。

1. 将报告作为需要验证的信息 #

收到Agent的报告，并不一定意味着报告内容已经得到充分核实。需要根据运维环境进行核查，判断这些信息能否用于决策。

BASTION将报告接收与防御判断的职责加以梳理，并采用根据验证结果进行响应的设计思路。

2. 限制操作范围 #

Agent可使用的功能和可操作的对象，将根据部署环境的要求加以限定。我们梳理所需的职责与权限，并确认对现有运维的影响。

限制权限只是措施之一，并不意味着仅靠这一点就能防止入侵或错误操作造成的所有影响。

3. 区分无法获得信息的状态 #

未收到报告、报告内容过时，或缺少核查所需的信息，都不能证明不存在问题。我们在作出判断的同时，也确认是否实际获得了观测信息。

我们重视让信息不足的情况可以被识别，并使运维人员能够据此核查和处理。

4. 同时确认对正常使用的影响 #

即使措施是为了防御，如果对象选错，也会影响正常用户和业务。需要一并梳理响应措施的适用范围、记录方式，以及运维人员核查和处理的步骤。

自动化的范围和必要的核查方式，应根据部署环境的条件进行评估。

5. 区分运维记录与防御效果 #

BASTION在核查自有环境的观测与响应历史的同时持续改进。不过，仅凭未观测到异常或误拦截，不能认定已经验证了遭受入侵时的防御效果。

我们根据使用条件进行验证，并区分已确认的范围与尚未确认的范围。

6. 部署时的核查与公开范围 #

部署前，需要梳理可获取的信息、连接条件、允许执行的操作，以及运维人员的核查步骤。配置与评估范围将根据目标环境和需求单独报价。

本文介绍设计思路，不刊载验证算法、控制条件、内部连接架构或客户的运维信息。当前功能和验证情况，请参阅BASTION服务介绍页面。