FSTEC合规审计：方法与证据

一家小型软件公司中标，负责维护一家假设的国家机构的预约门户。合同里有一行条款：新版本上线前，承包方须提交"FSTEC合规审计"结果。公司找来一家审计方，三周后拿到一份四十页的报告，几乎每一项都标着"符合"。报告依据的是开发团队自己发来的制度、规程和截图。

一个月后，客户自行检查。结果发现门户的管理后台可以从互联网直接访问，只靠密码保护，没有第二认证因素；登录日志只保留三天，而且没人查看。可安全策略里，这些内容都写得完全正确。

这个例子是假设的，不对应任何真实组织，但纸面与现实之间的落差并不陌生。"FSTEC审计"这个说法背后通常藏着三个不同的问题：哪些要求真正适用于该系统？防护措施是否真的在起作用？是否需要正式的信息化对象符合性评定（俄文：аттестация）——而任何审计、任何渗透测试都无法替代它？下文将讨论如何确定适用范围、如何以证据为基础开展检查、渗透测试处于什么位置、如何对不符合项排序，以及如何选择一家报告经得起复验的服务商。

人们订购"FSTEC审计"时实际买的是什么

FSTEC合规审计，是对信息系统、其防护措施及支撑流程在多大程度上满足俄罗斯联邦技术与出口管制局（FSTEC）适用于该系统的要求所做的结构化评估。关键词是"适用"。不存在一份"人人适用"的统一清单：不同的法规文件管辖不同类型的系统和不同类别的信息，不同类型的评估目标和法律后果也各不相同。

好的审计给出三项成果：对照具体要求的差距图景，并注明文件及其版本；证明措施确实有效的技术证据；以及一份可以向管理层、政府客户或监管机构说明理由的整改计划。差的审计只给出一张状态表，背后除了与系统所有者的往来邮件，什么也没有。

适用性从系统出发，而不是从服务名称出发

讨论方法之前，需要先回答三个问题。系统归谁所有：国家机关、国家机构，还是为政府客户运营系统的商业公司？系统处理什么信息：限制访问信息、个人数据，还是公开信息？评估目的是什么：内部差距分析、符合性评定（аттестация）准备、合同条件，还是重大变更后的检查？

答案决定以哪些文件为依据。国家信息系统中的信息保护是一套制度，个人数据保护是另一套，关键信息基础设施重要对象又是一套。后两者我们另有专文：依据152号联邦法开展的个人数据保护审计和关键信息基础设施审计。按"笼统的FSTEC要求"编制的报告，要么检查了不必要的内容，要么漏掉了强制性内容。

具体要求、防护等级和防护级别是否适用，应依据官方文本确定；有争议时，应请专门从事信息保护的律师参与。整个审计矩阵都取决于这一判断。

审计、渗透测试与信息化对象符合性评定是不同的工作

差距分析显示系统在哪些方面偏离要求。渗透测试显示攻击者在约定边界内实际能做到什么。信息化对象符合性评定（俄文：аттестация）是一项具有既定程序和法律后果的正式程序。渗透测试和漏洞扫描能为上述任何一项工作提供重要证据，但不会仅仅因为检查了与FSTEC要求相关的措施，就变成这种符合性评定。渗透测试既不是认证（certification），也不是信息化对象符合性评定（аттестация），更不是合规保证意见。

如果您需要的恰恰是技术部分——检验防护措施在外部接口、Web应用或内网中是否有效——最好事先约定边界：哪些系统在范围内，测试需要为哪些要求提供证据，生产环境允许哪些方法。Pentest.red开展此类测试，并可将结果整理成便于对照您的要求矩阵的形式；可以从渗透测试范围沟通页面开始。这不能替代信息化对象符合性评定（аттестация），也不能替代关于要求适用性的法律意见：这些需要另行进行有资质的评估。

2026年的法规基线：开工前要核实什么

旧报告和模板引用的文件会过时，这一点在2026年尤为明显。

对国家信息系统而言，关键变化是俄罗斯FSTEC 2025年4月11日第117号令，其内容为国家信息系统以及国家机关、国家单一制企业和国家机构的其他信息系统中的信息保护要求。该令于2025年6月16日在司法部登记，登记号82619，并自2026年3月1日起取代了此前的第17号令框架。

由此得出两点结论。今天编制的报告不应再把第17号令当作现行的国家信息系统通用要求来引用；只有作为历史背景时提及才合适，例如与以前的审计作比较时。而第117号令的适用范围，正如其标题所示，涵盖国家机关、国有单一制企业和国家机构的信息系统，并没有为所有私营公司建立一套普遍制度。合同可以向商业承包方传递合规支持或证据义务；第117号令是否直接适用于具体系统和运营方，需要另行判断。

另一项独立程序，是针对不构成国家秘密的限制访问信息保护要求进行的信息化对象符合性评定（аттестация）。其程序由俄罗斯FSTEC 2021年4月29日第77号令规定（2021年8月10日登记，登记号64589）。2026年2月27日第60号令对其作了修订，该令于2026年6月24日登记（登记号87202），并于2026年6月25日公布。仅以2021年文本描述该符合性评定程序，如今已不完整。

实践规则是：团队应依据适用文件的现行合并文本工作，而不是依据登记记录或别人的模板。评估频率——"每年一次""每两年一次"——也不能从一种制度类推到另一种制度。复评周期应取自具体适用的法规或合同。

为什么检查清单证明不了合规

信息保护要求通常表述为结果或措施：某些东西必须受到限制、被记录、被保护。文件审查能证实措施已被描述，却不能证实它在起作用：日志是否真的在写入并保存了规定期限，管理接口是否真的已关闭，补丁是否真的在安装。

NIST SP 800-115《信息安全测试与评估技术指南》明确指出技术检查的双重作用：既用于发现漏洞，也用于验证是否符合策略或其他要求。成熟的审计正建立在这一双重作用之上。同一项工作既发现弱点，又产出合规证据，因此只要事先把测试结果与要求挂钩，"审计"与"渗透测试"就不必是两个互不相干的项目。

需要说明的是：SP 800-115发布于2008年9月，取代了SP 800-42，其中没有现代工具。文件自称是对关键要素的概述，而不是一套详尽的方案。它是规划和记录检查的框架，而不是检查内容清单。

如果组织还需向境外合作方报告，NIST CSF 2.0会有帮助：现状与目标状态配置文件可以用管理层的语言描述同一状况，而无需重复现场工作。不应假定存在现成且权威的FSTEC要求与CSF映射；团队应记录所用映射，并逐条对照要求措辞而非章节标题进行验证。

方法：从要求到证据

规划、执行与执行后阶段

SP 800-115将评估分为三个阶段：规划、执行和执行后。规划阶段确定检查范围（系统、接口、站点、数据流）、带版本号的适用要求清单、工作规则，以及系统所有者的书面授权，其中写明目标、时间窗口、允许的方法和紧急停止联系人。没有这份授权，不得开始技术测试。

执行阶段收集证据：审查文件和配置、访谈、技术测试。执行后阶段是分析并撰写发现与建议。整改与复验则是下一个实践循环，由组织自己负责。它值得提前规划，但不应混入评估阶段，否则就说不清结论描述的是系统的哪个状态。

"要求—证据"矩阵

审计的核心是一张矩阵，其中每条要求都被改写为可检验的陈述。不是"确保记录安全事件"，而是"登录管理接口的事件会记录账户、时间和来源；日志保存不少于规定期限，并防止被篡改"。每条陈述都记录方法、证据类型、执行人、日期和结果：符合、部分符合、不符合或不适用——并附理由。

SP 800-115区分了审查类技术（文件、配置、日志）和测试类技术（扫描、渗透测试），并强调各自的局限。矩阵让方法的选择一目了然：哪些结论依据的是邮件里的截图，哪些依据的是可复现的测试。

版本纪律很有用。OWASP ASVS建议在要求编号中直接写入版本，例如v5.0.0-1.2.5，因为不同版本之间编号会变化。FSTEC要求同理：文件、版本、条款。从第17号令过渡到第117号令之后，不注明文件和日期的"某某条"引用毫无意义。

1. 适用性确定系统类型、信息类别、适用的法规文件及其包含修订在内的现行版本。
2. 可检验陈述把要求改写为关于系统的具体陈述，使其可以被证实或证伪。
3. 方法与授权选择破坏性最小且足够的方法，并取得技术检查的书面授权。
4. 证据从具体主机收集带日期的证据：导出文件、日志片段、测试记录。
5. 复验修复后用同一方法重复检查，并以新日期更新矩阵中的状态。

哪些证据可以接受，哪些不行

强证据与弱证据的区别不在于数量，而在于能否复核。没有日期和主机名的截图只说明某个配置曾在某处存在过。来自具体主机的带日期导出、测试结果和可重复的命令，才说明某个具体系统在某个具体时刻的状态。下表用于说明方法，而非复述某项法令的条款：确切措辞应取自适用的法规文件。

最后一列比看上去更重要：如果不清楚如何复验某个发现，"修复"之后剩下的就只有系统所有者的一句话。如何组织真正能证明问题的复验，请参阅我们关于渗透测试修复验证的文章。

技术检查：深度与运营风险的权衡

技术验证通常结合配置审查、漏洞扫描，以及在获准且合理的情况下进行的渗透测试。SP 800-115将其主题与审计与问责、风险评估、系统与通信保护、系统与信息完整性等控制族相对应——而这正是审计人员通常需要证实的内容。

破坏性最小且足够的方法

非侵入式审查几乎不影响运行，但可能遗漏可利用的弱点。主动测试提供更强的证据，但需要商定时间窗口和限制条件。对于处理受监管数据的生产系统，合理的做法是选择能提供足够证据、破坏性最小的方法；只有在要求措辞或风险水平需要、且系统所有者同意的情况下，才转向主动测试。

以一个假设的向公民开具证明的系统为例。密码策略可以通过导出目录配置、并尝试为测试账户设置弱密码来证实。但用户能否利用授权缺陷获取他人的证明，只能通过应用测试来证实——任何文件都回答不了这个问题。同一系统中的不同要求需要不同深度，矩阵必须反映这一点。

测试环境与生产环境

主动测试常被移到测试环境进行。这是合理的，但测试环境的结果不会自动适用于生产环境：版本、配置、网络规则、集成和数据都可能不同。如果结论涉及生产系统，矩阵中应说明以什么证实测试环境与生产环境一致，或者在生产环境中补充安全的检查，例如核对版本和访问规则。

可复现性

记录工具版本、扫描配置、时间窗口、原始输出和命令。这样，第二位复核人或监管机构就能看懂结论是如何得出的，复验时也能比较可比的内容。"未发现漏洞"如果不说明用什么、何时、在什么边界内查找，就什么也证明不了。

Web接口与API：应用层检查

许多受FSTEC要求约束的系统是门户、个人账户以及与其他部门交换数据的API。对它们而言，OWASP的方法纪律很有用，前提是报告中注明了标准版本。测试本身的详细内容，请参阅我们的Web应用漏洞测试指南。

OWASP WSTG定义测试用例，OWASP ASVS定义应用防护措施的可验证要求。具体矩阵可以选择并固定WSTG 4.2和ASVS 5.0.0；服务商必须明确说明实际使用的版本。ASVS要求提供CSV和JSON格式，便于导入矩阵。2025版OWASP Top 10是一份关于Web应用关键风险的意识类文件，适合与管理层沟通，但不是验证标准："覆盖Top 10"而没有ASVS要求和WSTG测试用例，只是弱证据。

应用层证据易于记录和复核。HTTP本身并不把请求彼此关联，应用通过cookie或令牌维持用户会话，会话数据完全可以保存在服务器端。因此，审计人员检查的是会话的实现方式：cookie属性（Secure、HttpOnly、SameSite）、登录后会话标识的更换、退出和超时后的会话终止。Content-Security-Policy响应头可以限制页面能加载哪些资源，有助于缓解跨站脚本和数据注入。CORS策略决定浏览器允许哪些第三方来源读取响应。如果过宽策略使非预期来源能够读取敏感的浏览器响应，它才构成实质性发现；严重性取决于凭据、数据和影响。API授权则通过访问他人对象和功能的测试用例来检查。所有这些都以带日期的"请求—响应"形式记录，修复后很容易重复。

不符合项排序：法规、可利用性与业务

缺少一份规程，与一个面向互联网且可绕过授权的管理后台，形式上都属于"不符合"，但以同样的紧迫程度去修复，显然不合理。

对于技术发现，映射到CWE弱点类别很有用。MITRE的2025年CWE Top 25列出了已公开漏洞背后最危险的弱点；MITRE指出，这些弱点往往容易发现和利用，可能导致系统被接管、数据被窃取或拒绝服务。CWE映射揭示根本原因，有助于修复一类缺陷而不是一个症状：如果某个API方法缺少授权检查，就应在相邻方法中查找同样的问题。MITRE还发布了2025年CWE Top 10 KEV弱点清单，依据CISA已知被利用漏洞目录中的漏洞进行排名。某弱点类别出现在基于KEV的排名中，只是优先级信号之一。具体发现是否已知被利用，需要该漏洞本身或观测活动的证据。

实用的严重性模型考虑三个维度：法规维度（是否违反适用法规的强制性要求）、技术维度（弱点类别、对外暴露程度、已知利用情况）和业务维度（影响哪些数据和流程）。只有"是"和"否"的报告，恰恰向管理层隐藏了决策所需的信息。详见我们关于基于风险的漏洞优先级排序的文章。

权衡与局限

文件审计更便宜、更快，但证据较弱。技术验证需要授权、协调和预算，却能显示措施的真实效果。通常合理的做法是组合：对面向互联网和高影响的系统进行技术测试，在要求措辞允许之处采用配置和文件审查。

一次性审计只反映某一天的状态，而配置会漂移，新版本会带来新的弱点。CISA在"设计即安全"（Secure by Design）材料中呼吁早在设计阶段就减少可利用缺陷，其安全软件部署指南也强调可靠测试和度量的作用。对审计而言，这意味着也要检查流程——变更如何进入生产、由谁审批、是否运行安全检查——而不仅是检查当天的配置。

国际指南不能替代本国要求。NIST、OWASP和CWE能提升证据质量，但合规性要对照适用的FSTEC文件评估。不比对措辞就把国际措施视为等同于本国措施，很容易造成虚假的合规感：例如，ASVS的日志要求在事件范围或保存期限上可能与某项具体法规的要求不同。

最后，内部团队了解环境，外部服务商带来独立性。如果适用要求对执行方类型或许可证有规定，应以此为准，并依据官方文本和登记册核实。

审计前、审计中与审计后

开工前需要：最新的系统清单、数据流图、指定的负责人、现行制度、已启用的日志、商定好的带版本适用文件清单、书面授权和工作规则。缺少这些，服务商就要花计费时间去重建基础信息。

审计过程中需要：快速沟通渠道、立即停止测试的条件，以及证据处理程序。审计材料包含配置和漏洞信息，因此要像保护系统本身一样严格保护：限制访问、受控存储、事先商定销毁期限。还应提前决定，发现严重问题时是立即通报还是等待最终报告。

审计结束后，不符合项转化为有负责人和期限的整改计划，随后用当初证实该发现的同一方法进行复验。这个"修复—复验—更新矩阵"的实践循环，在两次计划评估之间也值得持续运行；矩阵应持续维护，而不是归档了事。CSF 2.0配置文件为追踪从现状到目标状态的进展提供了方便的格式。

如何选择FSTEC审计服务商

只有在确定了适用要求、范围和深度之后，才值得比较服务商。CISA"按需安全"（Secure by Demand）指南是为与供应商谈判的软件采购方编写的，其逻辑同样适用于采购审计：提出可验证的问题，要求证据而不是营销说辞。

询问将使用哪些文件、哪些版本，以及服务商如何判断其适用性。了解方法：工作阶段、WSTG版本、ASVS版本和级别。索取一份匿名化的报告样本，其中应包含"要求—证据"矩阵。弄清楚发现如何映射到CWE并排序，授权、工作规则、停止条件和数据处理如何形成文件，以及合同是否包含复验。

如果范围内有第三方产品，请注意CISA的立场：产品应当开箱即安全，多因素认证、日志和单点登录应免费提供。审计人员通常会把这些功能与访问控制和事件记录要求对照，因此应提前确认您所用的产品版本是否提供这些功能并已启用。

危险信号包括：保证“通过”检查或符合性评定；没有技术部分；引用标准和法令却不注明版本和日期（包括把第17号令当作现行国家信息系统要求）；报告只有状态；拒绝出示匿名样本；承诺凭渗透测试结果完成符合性评定（аттестация）。如果适用要求规定执行方须具备许可证或其他授权，请在官方登记册中核实，而不是只听服务商的说法。

如果您打算单独采购审计中的技术部分，可以与Pentest.red具体讨论：系统和接口清单、测试需要支撑的要求、时间窗口和生产环境方面的限制，以及对证据格式和复验的期望。可以从范围说明页面或渗透测试服务页面开始。工作内容、周期和费用在分析范围后确定，而信息化对象符合性评定（аттестация）和要求的法律适用性问题仍由专业机构负责。

决策顺序：从哪里开始

首先确定适用性：系统类型、信息类别、具体法规文件及其现行版本。然后确定范围，为每条要求选择方法和证据类型，根据风险确定技术测试深度，并取得授权。之后才按可验证的标准选择服务商。接着对不符合项排序、整改、复验，并持续维护矩阵。在确定适用性之前就选择服务商，等于连同服务一起买下了别人对要求的解读。

经验法则（始终要对照具体要求的措辞核实）：如果Web应用或API面向互联网并处理受监管数据，应在适用范围内按选定且注明版本的WSTG和ASVS进行技术测试。对于其他技术，应选择与系统相适应的方法；对于影响较低的内部系统，如果要求措辞允许，文件和配置审查可能就足够了。

结论：合规靠证据证明

高质量的FSTEC合规审计回答的不是"有没有文件"，而是"措施是否有效，以什么证明"。适用性依据现行官方文本确定：自2026年3月1日起，国家信息系统信息保护的通用要求由第117号令规定，而第77号令规定的信息化对象符合性评定（аттестация）程序已由第60号令修订。方法框架来自SP 800-115的各阶段，应用的可验证要求和测试用例来自注明版本的ASVS和WSTG，按根本原因排序则依靠CWE类别。

在开头的假设例子中，矩阵中的一行引用现行版本的要求、一条针对该系统且有书面依据的“管理接口无法从互联网访问且要求第二因素”陈述，以及一次可复现的测试，就能揭示所描述的缺口。仅凭这些并不能确认系统符合全部适用要求。在这一框架中，渗透测试是强证据的来源，但不是信息化对象符合性评定（аттестация），也不是合规意见。当正确识别要求、带版本的方法、可复现的检查以及含复验的整改计划被整合为一项工作时，效果最好。