152-FZ审计：法律义务止于何处，技术证据从何开始

先看一个假设的例子，它不对应任何真实公司。一家网络零售商准备推出会员计划，包括网站注册、移动应用、保存购买记录的CRM、由承包商运营的呼叫中心，以及邮件营销服务。上线前一个月，管理层提出任务：“通过152-FZ审计并拿到证书”。预算只够做一项工作，大家倾向于对用户个人中心做一次渗透测试。这个决定看似简单，其实混合了三个不同的问题。法律是否适用，它给作为运营者的公司带来哪些义务？组织层面的义务是否落实，包括处理目的、法律依据、文件、角色以及与受托处理者的合同？具体系统中的技术措施是否像声明的那样运行？

渗透测试只能回答第三个问题的一部分。它可以成为有力的技术证据来源，但仅凭它无法确立对法律、组织和文件要求的符合性，也无法证明数据处理是合法的。私营机构开展的审计或渗透测试不是“152-FZ证书”，不是认证，也不是鉴证意见。下面讨论如何区分这几个层面，如何让技术部分建立在可复现的证据之上，以及买方应如何验收结果。

先确定法律适用性，再确定技术范围

俄罗斯联邦第152-FZ号法律《个人数据法》是俄罗斯个人数据领域的基本法律。其宣示的目的是在处理个人数据时保护个人和公民的权利与自由，包括隐私不受侵犯的权利以及个人和家庭秘密。该法经过多次重大修订，其中包括2022年通过的第266-FZ号联邦法律，因此2006年的原始文本或未注明日期的概述，都不能作为现行要求的可靠描述。关于某一运营者具体应当做什么的结论，需要合格的法律审查，并在开展工作之日对照现行合并文本加以核实。

对技术服务商来说，这引出一条实用规则：在输入条件明确之前，不要对范围下结论。否则渗透测试检查的会是方便检查的东西，而不是真正重要的东西。

运营者、处理目的与数据类别

第一步是记录谁是运营者，谁按照运营者的委托行事。在我们的例子中，零售商决定处理目的，而呼叫中心和邮件服务受其委托处理数据。接着描述处理目的：履行订单、运营会员计划、开展营销沟通。针对每个目的，记录数据类别和数据主体类别：顾客、会员、员工、交易对方代表。这些答案决定了哪些系统应当纳入审计，以及法律顾问需要审查哪些法律依据。

信息系统、威胁模型与保护等级

下一步是列出个人数据信息系统，建立威胁模型，并确定适用的保护等级。此类系统中保障个人数据安全的组织措施和技术措施的构成与内容，由俄罗斯联邦技术与出口管制局（FSTEC）2013年2月18日第21号令规定，该令于2013年5月14日在俄罗斯司法部登记，登记号为28375。与之并列的还有俄罗斯联邦政府第1119号决议、在使用密码保护时适用的俄罗斯联邦安全局（FSB）密码保护要求，以及后来的各项修订。这些文件必须按现行版本阅读，针对具体运营者的解释应由法律顾问与信息安全专家共同完成。技术团队的任务是把现成的威胁模型和保护等级作为输入，而不是在测试过程中自行设定。

三类工作及其边界

把审计拆分为三类工作会更清楚，它们由不同的人执行，产生不同的证据。法律工作回答哪些义务适用、处理是否合法。组织工作检查这些义务如何形成文件并得到执行，包括制度、内部命令、登记册、合同、同意、数据主体请求和安全事件的处理，以及员工的安全意识。技术工作检查系统是否做到了文件中声明的内容，包括访问控制、身份认证、日志记录、传输中数据保护、安全配置和漏洞管理。

最有用的发现位于各列的交界处，也就是声明状态与实际状态不一致的地方。高质量的审计会把每一项重要的文件声明对应到一项技术检查，并把无法测试的声明明确标注为未验证。

渗透测试能证明什么，不能证明什么

NIST SP 800-115指出，技术测试有两个用途：发现漏洞，以及验证是否符合策略或其他要求。正是第二个用途让渗透测试对个人数据审计有价值：它能显示某项声明的措施是否真正有效。但同一文件也明确说明，它并不是一套完整的测试计划。渗透测试无法告诉你处理目的是否合法、同意是否充分、保护等级是否确定正确、通知义务是否已经履行。关于如何把测试纳入检查准备工作，可以参阅关于面向审计准备的渗透测试的文章。

清单：系统、数据流与明确的排除项

审计质量受限于审计范围。系统清单包括数据库、CRM和人事系统、公开网站及其表单、移动应用、API、文件存储、备份以及承包商的系统。凡是没有列入清单的系统，无论最终报告怎么写，实际上都没有被审计。在我们的例子中，很容易忽略发给邮件服务的导出文件，以及呼叫中心在CRM中的账号，而数据恰恰是在这些地方离开核心边界的。

接下来绘制数据流：收集、传输、存储、处理、向第三方提供以及删除。数据流图不是为了写报告而写报告，它能显示哪些节点必须纳入测试计划，以及责任在哪里转移给承包商。

网页表单、Cookie与会话

大量数据是通过网页收集的。HTTP协议本身不保存状态，状态由Cookie增加：服务器发送Set-Cookie头，浏览器在之后的每次请求中带回该值。因此，个人中心和注册表单中的会话标识符，既应出现在数据流图上，也应写进检查计划。

排除项是一项决定，而不是默认处理

如果承包商托管的系统或遗留应用不在范围内，报告应当写明并说明原因。管理层和日后的检查人员都不应需要猜测究竟检查了什么。参照NIST CSF 2.0思路建立的当前配置文件和目标配置文件，有助于记录起点和目标，让整改计划具备结构，而不是变成一份平铺的问题清单。

技术方法：从计划到报告

技术部分分为三个阶段。规划阶段确定范围、工作规则、测试时间窗口、联系人和升级路径。执行阶段结合文档与配置审查、漏洞扫描，以及仅在获得明确授权时进行的渗透测试。分析阶段把观察结果整理成按优先级排列的发现，附上建议，并注明每项发现是通过哪种手段得到的。

授权与工作规则

任何主动测试都需要系统所有者的明确书面授权，并写明范围、目标和时间窗口。托管在服务商或承包商处的系统，还需要取得对方的同意。在零售商的例子中，如果呼叫中心对CRM的访问在范围之内，就需要与呼叫中心单独协商。本文任何内容都不构成、也不暗示对任何系统进行测试的授权。

处理真实个人数据

存有真实记录的系统需要额外的规则：尽量少接触数据；证明漏洞存在即可，不批量提取记录；意外接触敏感信息时立即通知客户。合同应规定可能含有个人数据的工作产物如何存储、保护和销毁，例如截图、日志和导出文件。审计本身不应成为新的泄露渠道。

Web应用与API：可以重复的检查

Web应用和API通常是个人数据进入系统的入口，因此需要一份结构化的测试目录，而不是笼统的表述。OWASP Web安全测试指南（WSTG）提供了这样的目录：工作计划可以引用WSTG的具体测试领域，这样覆盖范围一目了然，也便于在不同服务商之间比较。如何以标准为基础开展Web应用检查，可参阅关于Web应用漏洞测试的文章。

用带版本号的要求代替笼统引用

OWASP ASVS规定了技术安全控制要求，并建议引用时注明版本，例如采用v5.0.0-1.2.5的形式，因为编号可能随版本发生变化。对审计而言，这意味着买方与服务商事先约定适用的ASVS章节和级别，发现项引用带版本号的标识符，复测时评估的就是完全相同的要求。OWASP Top 10适合用作共同语言，但如果报告只写“已按Top 10检查”，其证据力度不如与WSTG测试和ASVS要求逐一对应的报告。把标准与管理决策联系起来的方法，可参阅关于应用安全审计的文章。

HTTP层面与基础安全卫生

有些措施可以直接在收集数据的页面上看到：Cookie属性；Content-Security-Policy头，它有助于发现并缓解跨站脚本和数据注入；用于跨站请求的CORS设置；以及用于限制浏览器功能的Permissions Policy。这类检查成本低、可重复，是证明基础安全卫生的有力证据，但不能替代对访问逻辑的测试。

按数据风险确定发现的优先级

在个人数据审计中，主要风险是数据被窃取或泄露，因此应当按照对数据的影响而不是数量来排列发现。CWE Top 25的根因类别有助于把具体错误与弱点类别联系起来，而与CISA已知被利用漏洞目录（KEV）相关的弱点清单，则提示哪些发现应排在纯理论性发现之前。

多个独立来源指向同样的缺陷类别：跨站脚本、操作系统命令注入和目录遍历。这意味着，任何处理个人数据的Web系统都应把注入类和跨站脚本检查纳入范围。另外，还值得检查CISA视为“开箱即安全”的基础措施：管理员和特权访问是否启用了多因素认证，日志是否开启并得到保存，在产品支持的情况下访问是否集中管理。

整改与复测：应当接受哪些证据

发现报告只是工作的中点，而不是终点。只有当整改由发现问题时的同一项检查加以确认，运营者才真正获得价值。如何跟踪修复并加以证明，可参阅关于漏洞整改控制的详细文章。

1. 记录写明发现所在的系统、复现条件、证据以及带版本号的要求引用
2. 修复系统所有者完成修复，并说明改了什么、改在哪里
3. 复测服务商使用同一手段、针对同一版本的要求重复原始测试
4. 验收只有得到可复现的否定结果才关闭发现，否则退回系统所有者

验收标准

如果某项修复无法用技术手段验证，例如修改与受托处理者签订的合同，就应把它记录为组织层面的证据。这类证据由法律顾问或负责组织数据处理的人员评估，而不是由技术服务商评估。

深度与保证成本之间的权衡

技术部分的深度取决于系统的暴露程度和数据的敏感程度。如果系统可从互联网访问、存有大量或敏感类别的数据，或者自上次评估以来发生了明显变化，就有理由进行完整测试。对于小型内部系统，文件审查加配置分析可能就足够了，但这一决定应作为有意识的范围选择写进报告。

审查文件还是实际测试

审查文件更快，对业务的干扰也更小，但只能声称措施存在。实际测试需要授权和协调，却能证明这些措施是否真正有效。

自动化还是人工

扫描覆盖面广、结果可重复，但会漏掉业务逻辑和访问控制方面的缺陷。人工测试能够发现这些缺陷，但在同样时间内覆盖的范围更小。有说服力的报告会把两种方法结合起来，并注明每项发现的来源。

生产环境还是测试环境

在生产环境中测试更真实，但会给可用性和真实数据带来风险。常见的折中做法是：在有代表性的测试环境中进行主动测试，而在生产环境中只做被动配置审查和事先约定的低影响检查。无论如何，任何审计都只是某一时刻的快照：发生重大变更后应重新评估，评估频率则应根据风险以及法律顾问确认的要求来确定。

如何选择服务商，以及不应向其提出什么要求

只有在范围和目的明确之后才选择服务商，否则无法比较各家方案。评估时看三点：方法是否透明；服务商能否覆盖所需的层面，或者坦率说明哪些层面仍需由法律顾问负责；以及工作中如何处理个人数据。如果需要对照监管要求检查组织措施和技术措施，可以把思路与关于FSTEC合规审计的文章对照。实用的下一步是描述技术部分的范围：系统、访问权限、限制条件和预期证据，可以事先在Pentest.red的渗透测试范围准备页面上整理好。

询问法律顾问认为本次范围需要哪些许可或资质，并在官方登记中核实。没有可核查文件支持的认证声明或过往业绩，不应采信。

向服务商提出的问题

将采用哪些方法和版本，发现项将引用哪些标识符？文件声明如何对应到技术检查，无法验证的声明如何在报告中体现？开始主动测试之前需要哪些书面授权和工作规则？含有个人数据的工作产物如何存储和销毁？是否包含复测，条件是什么？结果将包含哪些内容：范围与排除项、方法、证据、风险评级和整改计划？

危险信号

以下情况值得警惕：不检查任何实际系统就交付模板化文件包；不要求书面授权；说不出所用方法；发现项没有可复现的证据；承诺“保证通过检查”；把结果称为152-FZ合规证书。没有任何方法支持对结果作出保证，技术报告也不是认证、资质评定或合规意见。

委托之前需要决定什么

回到这家假设的零售商。管理层需要的不是一张“证书”，而是三项清晰的成果。第一，由法律顾问依据法律及下位法规现行版本确认的适用义务全貌。第二，经过核查的组织措施，包括文件、角色、与受托处理者的合同，以及处理数据主体请求的流程。第三，针对会员计划各系统的技术证据，附有带版本号的要求引用、书面授权、每项发现的证据以及复测结果。

在这样的安排中，渗透测试是重要的证据来源，但只是其中之一。它能说明个人数据实际暴露在哪里，并给出一份可以核验的修复计划。而是否上线，应当综合三个层面作出判断，而不是只看一份报告。