公司新上了云办公系统，IT部门说‘边界已加固’，业务部门觉得‘系统能用就行’，安全团队发了三次风险提示邮件，没人回复。某天勒索病毒从公网入口钻进来，加密了财务系统——这时候，到底该找谁？
边界不是一堵墙，而是一条责任线
很多人以为‘网络边界’就是防火墙那台设备，插上网线、配好策略，就万事大吉。其实不然。边界是动态的：员工用手机连WiFi访问内部OA、销售用个人笔记本接入客户VPN、运维通过跳板机直连生产库……这些动作都在悄悄改写边界的形状。
责任划分，本质上是在回答三个问题：
谁决定哪些流量能进？
谁确认进来的流量没带恶意载荷？
谁为‘不该进却进了’的结果担责？
常见场景里的责任错位
场景1：外包系统上线
市场部引入一款SaaS客服工具，要求开放443端口直连。网络组按需开通，但未校验该SaaS是否启用WAF或日志审计。后来发现对方API密钥硬编码在前端被爬走——漏洞在对方，暴露面在我方。责任落在谁身上？合同里没写清楚访问控制责任，最后由信息科补丁、法务部补协议。
场景2：混合云架构
私有云和阿里云VPC通过高速通道互联。安全策略只管IDC侧防火墙，云上安全组全开。攻击者利用云主机弱口令横向移动到核心数据库。这时，IDC网络管理员说‘我的设备没问题’，云平台负责人说‘我只管资源交付’。边界策略的断点，恰恰成了责任真空带。
划清四类责任主体
1. 业务方：提出接入需求时，必须明确说明数据敏感级别、访问来源、预期并发量。不能只说‘要能用’，得说‘哪些人、从哪、用什么方式、查什么数据’。
2. 网络/基础设施团队：负责执行最小权限策略。比如开放端口必须绑定源IP段，VPN账号必须绑定设备指纹，云上安全组禁止0.0.0.0/0入向规则。配置变更需留痕，且保留72小时回滚能力。
3. 安全团队：不代替别人干活，但要守住底线。例如：所有出向DNS请求必须经统一解析网关；所有互联网出口流量需经IPS+沙箱检测；边界设备日志必须实时进SIEM并设置异常登录告警。
4. 第三方服务商：在合同附件中强制写明安全义务。例如：‘乙方系统若提供API接口，须默认启用OAuth2.0鉴权，且Token有效期≤1小时’。别让‘以双方协商为准’变成事后扯皮的万能话术。
一个落地建议：画一张活的边界责任图
不用画多精美，用Excel也行。列四栏：
• 边界节点（如：DMZ区Nginx、办公网SSL VPN网关、云WAF实例）
• 当前策略（如：仅允许80/443，源IP限办公网段）
• 责任人（具体到姓名+手机号，不是‘网络组’）
• 最后验证时间（精确到日，每月自动提醒复核）
这张表不进PPT，只贴在运维群置顶。上次某公司靠它快速定位到‘测试环境API网关策略半年未更新’，提前拦住一次越权调用。