边界安全概念：网络、身份、数据的定义与相互关系

聊权限模型之前，我觉得有必要先把这个“边界”的事儿说清楚。

很多人一谈安全，脑子里反应的是防火墙、VPN，说白了就是网络隔离。但这套思路放到今天，其实已经有点吃力了。你想想看，员工在家办公，资源在云上，API直连数据库——传统网络边界早就被捅成了筛子。

所以我个人习惯把边界拆成三层来看：网络边界、身份边界、数据边界。这三层不是替代关系，是叠在一起打的。

1. 网络边界：最熟悉的陌生人

网络边界是大家最熟的。防火墙、DMZ、VPC、安全组，都属于这层。它的核心思路是：从哪儿来，到哪儿去。

我记得早期做IDC迁移时，团队花了两周画网络拓扑图，哪段IP能访问哪段，规则列得密密麻麻。结果呢？一台跳板机被拿下，整个内网就裸奔了。

现在的做法是：网络边界依然要守，但不能只靠它。把它当作第一道筛子，而不是唯一防线。

2. 身份边界：你是谁，能干什么

身份边界的核心是认证与授权。它不看你从哪个IP来，只看你是谁、有什么凭证、能操作哪些资源。

说白了，身份边界把信任从“网络位置”转移到了“数字身份”上。IAM、SSO、MFA、RBAC，都是这层的工具。

我在项目中遇到过一件事：某团队把所有微服务放在一个K8s集群里，网络策略做到互相隔离，但所有service account只用同一个。嗯，这就是典型的“网络边界守住了，身份边界一塌糊涂”。攻破一个Pod，就等于拿到所有Pod的权限。

3. 数据边界：最后一道闸

数据边界是目前很多企业做得最弱的一环。它关注的是数据本身：谁可以读、谁可以写、谁能删、谁能导出。

我曾经帮一家金融客户做审计，发现他们的敏感数据在数据库里全是明文存储，应用层的权限控制写得也还行，但DBA可以直接Dump整张表。这叫什么？权限模型到了数据层就断掉了。

数据边界要依赖以下几件事：

• 字段级权限：不是所有人看客户信息都需要看到身份证号
• 数据分类分级：公开、内部、敏感、绝密，每个级别对应不同策略
• 动态脱敏：根据请求上下文动态决定数据展示形式
• 审计日志：谁、在什么时间、从哪个应用、访问了哪条数据

我个人建议：数据边界的建设，要从数据字典和分类开始，而不是一上来就搞加密。

4. 三层边界的关系：一个叠一个

这三层不能割裂看，它们是串联防御的关系。我画过一张图，能很直观地展示它的运作方式：

从这张图可以看出，请求必须依次穿过三层，每一层都可能被阻断。

我踩过的坑里最常见的就是：只配了网络策略，没配应用层权限，结果系统之间互相调用时权限失控。或者反过来，应用层权限做的很细，但DB端口开放——简直就是开着门锁门。

5. 三层边界的具体对比

维度	网络边界	身份边界	数据边界
控制对象	IP、端口、协议	用户、角色、服务账户	数据行、字段、文件
信任模型	隐式信任（内网秒过）	显式验证每次请求	最小化权限曝光
典型工具	防火墙、安全组、NAC	IAM、SSO、MFA	加密、脱敏、DLP
绕过风险	跳板机、VPN突破	凭证泄露、窃取	DBA直连、API未鉴权
建设顺序	第一道防线	核心防线	最后屏障

说实话，大部分公司第一道和第二道能做好就不错了。第三道数据边界，很多还停留在“数据库加密即安”的阶段。

我觉得这里面最容易被忽略的地方是：数据边界不是靠一个工具能解决的。它需要数据分类、权限模型、审计能力三者联动。比如，你先得知道哪些字段是敏感字段，才能决定字段级权限怎么写。

6. 在权限模型中怎么用这三层边界

具体到权限模型设计，我个人习惯这样分配职责：

1. 网络边界：限制服务间的调用来源，防止非预期流量
2. 身份边界：用户在应用层面的角色、资源权限、操作权限
3. 数据边界：根据请求上下文，判断用户能看哪些数据实例

举个例子。一个银行系统的转账接口：

• 网络边界：只允许前端网关IP访问该服务，其他来源直接DROP
• 身份边界：只有经过OAuth认证且拥有“转账操作员”角色的用户才能调用
• 数据边界：该用户只能转其关联客户账户内的资金，不能操作他人账户

你想想看，缺少任何一层，都可能出大问题。少网络层，攻击者可能绕过网关直接调API；少身份层，任何人只要拿到内网IP就能用这个接口；少数据层，内部人员可以随意转账给别人。

嗯，这就是三层边界的实战意义。不是炫技，而是必须这么干。