📚 课程目录第3章边界设计基础

边界设计基础：系统边界、网络边界与业务边界

聊边界设计之前，我想先说个事儿。

有次我审计一家企业的供应链系统，对方运维拍着胸脯说“我们边界防护很严”。结果我一问，他们所谓的边界就是防火墙ACL。那个系统背后关联了十几个外部API，有的甚至还直连生产库。你看，他们只看到了网络边界，却完全忽略了业务边界和系统边界。

这就是典型的边界认知盲区。在实践中，边界至少得拆成三层来看：系统边界、网络边界、业务边界。每一层的职责、风险点、审计方法都不一样。

系统边界，说白了就是一个软件单元对外暴露的接口范围。

你写了一个微服务，它接收什么请求、返回什么数据、依赖哪些下游——这些就是系统边界。我见过太多项目，开发只盯着功能实现，对系统边界完全没概念。结果呢？服务A直接调服务B的数据库，服务C把内部缓存暴露给了前端。嗯，这些都是在日常项目中真实踩过的坑。

怎么定义系统边界？我个人习惯用三个维度来卡：

我的小技巧：审计系统边界时，直接让开发同学画出“系统上下文图”。如果五分钟画不出来，说明边界设计有问题。

举个例子。一个订单服务，它对外提供了查询订单的HTTP接口。系统边界就是/api/order/query这个端点。任何请求，只要到了这个端点，就进入了系统边界。但问题是：这个端点要不要做鉴权？要不要做限流？参数要不要做边界校验？这些都是边界设计要回答的问题。

我曾经审计过一个项目，订单服务的系统边界被设计成“全开放”模式——所有接口都不鉴权，理由是内网调用。结果有个前端工程师好奇，直接在浏览器里调了关单接口，把一个生产环境的订单给关了。你看，系统边界不清，后果很直接。

网络边界是最熟悉的面孔。防火墙、WAF、VPN、DMZ……这些是老生常谈。但我得说，你懂网络边界 ≠ 你能设计好网络边界。

网络边界的设计核心就一句话：谁在什么条件下能访问谁的哪个端口。

把它拆开来看：

你看，就这么一层简单的关系，很多公司做成了“全通”或者“全闭”。全通的网络边界等于没有边界，全闭的网络边界业务跑不起来。这里面的平衡点，才是最考验设计能力和审计能力的地方。

避坑指南：我曾经见过一个客户，网络边界策略写了三百条ACL，看似很严谨。结果一审计，里面有三分之一是重复规则，还有几十条只写了源IP没写目标，等于废纸。网络边界不光是“有”，还得“有效”。

网络边界有个常见误区——只关注南北向（外部到内部），忽略东西向（内部到内部）。微服务架构下，东西向流量往往是安全重灾区。我记得有次做渗透测试，从一台被攻破的应用容器出发，横向移动了三跳就拿到了数据库权限。这就是内部网络边界形同虚设的活例。

至于具体的网络边界实现手段，不外乎：

嗯，核心原则就一条：最小权限。用到什么开什么，用完就关。

业务边界这个概念，很多技术背景的人不太重视。你想想看，系统边界和网络边界都是技术层面可以丈量的东西，但业务边界涉及到为什么要有这个系统、数据在什么业务场景下流转。

我个人对业务边界的定义是：一组相互关联的业务活动所涉及的数据、规则和操作域。

说得更直白一点：

这些问题，系统边界和网络边界都回答不了，必须由业务边界来回答。

我在做审计时，会特别关注以下业务边界的“冲突点”：

业务边界的划分没有银弹，但我给一个自己常用的框架，四个步骤：

    核心要点：业务边界不是一成不变的。随着业务演进，边界会漂移。审计的目的不是制定百年不变的边界，而是确保每一次边界变动都有评审、有记录、有验证。

这三类边界不是互相独立的。做个不恰当的比喻：

你设计好了业务边界，才能准确定义系统边界；定义好了系统边界，网络边界的设计才有依据。反过来，网络边界的策略也会制约系统边界的灵活度，系统边界的实现细节又会影响业务边界能否落地。

这就像三个环互相嵌套，少一个都不行。

下面这张图我把三类边界以及它们之间的审计关注点画在了一起。你读完正文再看图，应该会更有感觉。

三类边界各自独立又互相影响，所以在做审计时，不能只盯着某一层看。我总结了三个融合审计的切入点，你可以拿去直接用：

    一句话总结：边界设计的本质是“定范围、定权限、定协议”。审计的本质是“看范围是否合理、权限是否最小、协议是否执行”。

说实话，这三类边界的设计和审计，一开始确实有点绕。但你多做几个项目就会发现，那些安全事故，十有八九都出在“边界模糊”或者“边界不一致”上。把边界理清楚了，很多问题自然就暴露出来了。