如何在不记录浏览历史的情况下留存 VPN 访问审批
只保留身份、审批人和有效期,跳过访问目标清单。三个条件决定访问决策中究竟有多少内容需要真正入档。
两个团队要的是同一份材料,理解却不一样。评审人想证明某个具名人员在某个日期前批准过一项角色,而网络团队手里有一份满是访问目标的防火墙日志,并认为这就够了。这并不够,所以审批文件夹里塞满了主机名,却仍然通不过第一个审计问题。你真正需要的东西很少,而且其中没有任何一项要求记录某个人浏览过哪里。
记录的大小取决于三个条件:审批是按人授予还是按角色授予,该权限是否可能在人员的雇佣关系结束后继续存在,以及合同或框架是否把访问复核列为必须提供的证据。
从评审人的问题出发,而不是从连接出发
在挑选任何一个字段之前,先写下审计人会大声提出的问题。谁批准了这个身份对什么的访问,起止日期是哪天到哪天,最后应当由谁撤销。表单上的每个字段都应回答那句话的一部分,凡是做不到的,都是你刚刚承担了保护义务的清单。
这一检验会剔除大部分出于习惯而添加的内容。目标清单、DNS 查询、应用使用图表和实时会话截图描述的都是行为。行为不是审批,收集它会让档案进入敏感级别高得多的类别,与你最初的目标背道而驰。
三个条件决定留存多少
按人授予的审批需要身份和结束日期。按角色授予的审批需要角色、它所授予的范围以及群体负责人,因为在一行里列出四十个人,就意味着要维护四十条记录,也有四十次漏掉离职的机会。当权限可能在雇佣关系结束后继续存在时,还要加上撤销负责人和复核节奏,因为电子表格里的到期日很少能促使任何人采取行动。
| Condition | Add to the record | Leave out |
|---|---|---|
| Approved per person | Identity, approver, expiry | Device telemetry |
| Approved per role | Role, scope, population owner | Per-user destinations |
| Outlives employment | Removal owner, review date | Session transcripts |
| Named in a contract | The cited artifact and its revision | A second, friendlier copy |
当某个框架把访问复核列为必须提供的证据时,保留复核流程已经引用的那份材料。为 VPN 团队另建一份平行副本,正是同一份审批的两个版本最终在结束日期上互相矛盾的原因。
承载决策的字段
可用的字段组合很短:获批准的身份、申请人、审批人、角色或资源范围、一句话理由、生效区间、复核或撤销负责人,以及指向请求讨论所在工单的链接。设备或凭据要用非机密的标识来引用,例如资产标签或证书主体,绝不能用所用过的私钥或口令。
即使不含访问目标,也要把结果当作个人数据。一条写着这名具名员工在六个月内拥有财务网段管理权限的记录,本身就属于敏感信息,所以要限定谁可以读取该文件夹,并按管理目的设定保存期限,而不是把档案称为匿名数据。
浏览数据从哪里混进审批档案
大约三类泄漏就能解释大部分情况。服务台工单里带着客户端连接窗口的截图,有人为补充背景贴了一份 SIEM 导出,或者因为当时做关联很容易,就把资产清单报表并进了审批。每一份附件都给只需要一个决定的档案添上了行为。截图一旦进入,评审人就开始追问用户在访问什么,档案也就必须重新定级。
凡是工具允许,就用链接代替附件。如果政策坚持要有附件,就要决定文本和请求串,而不是会话录像;并在存档前把其余部分删掉。审批人自己的消息通常是最好的证据,也是暴露最少的一份。
在没有痕迹的情况下验证范围
把审批变成访问的是网关策略,所以直接去测试它。用已批准范围内的一枚账号登录,并访问一个被允许的资源,然后尝试范围之外的目标并确认被拒绝,使用策略所预期的客户端和方法,而不是同一台主机上的浏览器窗口。
可用性监控和事件诊断可以保留自己的可见性,在各自的保存期限和各自的访问名单下运行。把这两个目的分开,正是让你能在不交出浏览痕迹的前提下回答评审人的原因,也让诊断在真正出故障时仍然有用。
下一次复核之前要检查什么
确认表单回答了审计人的那句话,而且不多答。检查每一行都带有审批人、区间和撤销负责人。然后看看该文件夹自己的访问名单,问一句它是否比 VPN 用户群更小。
最后一步是人们常跳过的那一步。挑一条已过期的审批,顺着它找到身份提供方,看账号是否真的被停用。如果身份仍然有效,那么记录是准确的,流程不是。