SRAA 全称 Security Risk Assessment and Audit：香港政府的安全风险评估与审计，到底在评什么

在香港做安全合规，你一定绕不开一个词：SRAA。全称 Security Risk Assessment and Audit，中文叫”安全风险评估与审计”（也译作”保安风险评估及审计”）。它不是某个厂商的产品，而是香港政府制定的一套强制性的安全评估与审计要求，所有政府部门、局/署（B/Ds）以及政府资助的机构，都必须按它执行并提交独立核证报告。

这套要求的落地依据，是数字政策办公室（Digital Policy Office，DPO，前身就是 OGCIO）发布的《Practice Guide for Security Risk Assessment & Audit》（编号 ISPG-SM01），配套文件还有《Baseline IT Security Policy》[S17] 和《IT Security Guidelines》[G3]。2026 年 8 月发布的最新版是 v2.2，新增了一份”SRAA 过程与交付物基线检查表”。

它的规范性引用也挺能说明定位：ISO/IEC 27000、27001、27002、27005，ISO 31000:2018 风险管理指南，以及 NISTIR 8286（把网络安全并入企业风险管理 ERM）。换句话说，SRAA 是一套把国际标准”本地化落地”的政府级框架。

一句话分清 SRA 和 SA

很多人把 SRAA 当成一件事，其实它是两件事的组合，性质完全不同：

• Security Risk Assessment（SRA，安全风险评估）：识别、分析、评估安全风险，并确定处置措施，把风险降到可接受水平。视角是”风险“，评估范围不一定跟安全政策挂钩。
• Security Audit（SA，安全审计）：审计对安全政策/标准的合规程度，验证现有防护措施是否被正确执行。视角是”合规“，对照的是 S17、G3 或部门自己的安全政策。

官方给了一张对比表，把差异讲得很干脆：

• 关注点：SRA 是风险视角；SA 是合规视角
• 执行方：SRA 可以由部门自己评（自评估），也可以找第三方；SA 必须由独立第三方完成
• 关键交付物：SRA 交风险登记册（risk register）+ 风险处置措施；SA 交合规检查表（compliance checklist）
• 时机：新系统在开发生命周期（SDLC）起点做 SRA；已上线系统则在整个生命周期内定期做，或 IT 环境发生重大变更时做

三个最常见的误解，先纠正

ISPG-SM01 从 2.0 版（2024 年 4 月）起专门澄清了几个流传很广的错误认知，做这行的应该都听过：

• 误解一：必须 SRA 和 SA 一起做，出一份”二合一”报告。错。两者性质不同，执行方要求也不同（SA 必须独立第三方），可以分开做。
• 误解二：一次 SRAA 活动就能同时覆盖 SDLC 里的风险识别和合规检查。错。这是两类不同的工作。
• 误解三：SRAA 就是漏洞扫描或渗透测试。错得最离谱。渗透测试只是 SRA 里”技术漏洞测试”环节的一部分工具，不是 SRAA 本身。不少顾问公司在自己服务介绍里都写错了，说”SRA 通常包含渗透测试流程”。

把这一点说清楚很重要——因为如果你按”渗透测试”去准备 SRAA，方向从一开始就偏了。

SRA 怎么做：四步走

系统级的安全风险评估，主线是四个环节，最后沉淀成系统风险登记册：

风险识别（Risk Identification） → 风险分析（Risk Analysis） → 风险评价（Risk Evaluation） → 风险处置（Risk Treatment）

风险的定义很直白：风险 = 威胁 × 漏洞 × 影响。威胁可能来自个人、组织甚至环境条件，导致未授权访问、信息破坏/篡改或拒绝服务；漏洞则是安全体系中可被威胁利用的弱点或缺口。

风险识别阶段要覆盖的方面很广，官方列了十大块：人力资源安全、资产管理、访问控制、密码学、物理与环境安全、运营安全、通信安全、系统采购开发与维护、外包安全，以及业务连续性的 IT 安全。识别过程又分两个子过程：

• 信息系统识别：把管辖范围内所有信息系统（不论资金来源）都盘出来，做资产清单和估值。资产价值分三类——有形价值（设备/软件/数据/文档/人员的重置成本）、无形价值（商誉、服务质量）、信息价值（CIA 三性 + 数据分类）。
• 风险场景识别：要考虑风险来源、原因与事件、威胁与机会、漏洞与能力、内外部环境变化、新兴风险指标、资产性质与价值、后果与影响、知识局限与信息可靠性、时间因素等。

识别时收集的资料也很具体：安全需求与目标、系统/网络架构与拓扑图、机房物理环境是否达标的证据、公开可查信息、物理资产、操作系统与网管系统、数据库与文件、应用与服务器信息、网络协议与服务、访问控制措施、各类操作流程、身份认证机制、法规合同要求、政策指南、系统分级。

其中系统审查要重点看：系统文件与日志、运行进程、访问控制文件、用户列表、配置设置、补丁级别、加密或认证工具、网管工具、日志或入侵检测工具——同时要留意有没有入侵尝试之类的异常活动。

必要时才做技术漏洞测试：漏洞扫描、渗透测试、配置审查、源代码扫描。关键前提：动手前，评估团队必须就范围、可能影响、回退/恢复程序与部门达成一致；如果涉及 Tier 2 及以上系统，还要参照业务连续性计划（BCP）和灾难恢复计划（DRP）。漏洞扫描要覆盖网络层探测/发现、主机漏洞测试、系统/应用（含 Web）扫描，并核查是否对 GovCERT.HK 发布的相关安全公告都已打补丁或有补偿措施。

风险怎么算：三级矩阵

风险分析要评估影响和可能性，还要识别现有控制并评估其有效性。控制分三类：技术控制（防火墙、加密、防恶意软件、访问控制）、物理控制（CCTV、门禁、消防、物理数据销毁）、管理控制（应急响应计划、员工安全培训、数据隐私政策、灾备计划）。

分析方法有定性和定量两类，也可用矩阵法。一个实用的公式是：

风险等级 = 影响 × 可能性 × 系统分级（Tier）

每项取值 3-高 / 2-中 / 1-低，乘出来范围 1 到 27：18-27 为高风险，9-17 为中风险，1-8 为低风险。而且不同 Tier 的系统有各自的风险矩阵——同样”中等可能性 + 高影响”，Tier 1 算中风险，Tier 2 就算高风险，Tier 3 更是高风险。系统分级越高，容错空间越小。

官方还给了两个估算技巧：一是基于既往事件（参考安全事件报告、行业文献、服务商的历史泄露数据）；二是三点估算法（Three-Point Estimation），让专家分别给出最乐观 O、最可能 M、最悲观 P 三个值，用三角分布取平均。如果 P 和 O 差距太大、M 更可靠，可以给 M 加权（比如四倍权重）。

SA 怎么做：合规检查

安全审计走的是另一条线：通过文档审查、现场走访、多层级访谈、小组讨论、问卷等方式，对照 S17 和部门安全政策做合规检查。审计范围必须具体且事先与审计师达成一致，官方给的示例包括：互联网安全、内网通用安全、Tier 2 信息系统、主机安全、网络服务器安全（Web/邮件服务器等）、网络组件与设备（防火墙、路由器）、机房通用安全、网络服务（目录服务、邮件服务、远程访问）、系统文档与记录。

对于部门级或不特定范围的审计，通常做法是审计 S17 定义的 ISMS 或组织自有 ISMS 框架（政策/标准/程序）的规模与有效性。

交付物与 10 项常见活动

官方把整个 SRAA 的常见活动梳理成 10 项，基本就是一份实操路线图：

1. 启动会议：确认服务范围、目标、交付物
2. 项目规划：商定交付时间表和工期
3. 准备检查表：与部门确认检查表
4. 准备回退/恢复程序：针对漏洞扫描、渗透测试等技术测试
5. 资产识别与估值：在约定范围内识别评估资产
6. 风险评估：风险识别 → 风险分析 → 风险评价
7. 交付 SRA 报告、风险处置计划、系统风险登记册
8. 向管理层汇报上述结果与发现
9. 安全审计：合规检查 → 交付审计报告 → 汇报审计结果
10. 数据与结果保护、跟进计划、保障实施审查、交付验证报告、闭环汇报

可以看到，交付物不是一份报告就完事：SRA 侧交风险登记册和处置计划，SA 侧交合规检查表和审计报告，最后还要有验证报告来确认每一项发现的整改结果，才算闭环。

谁来做，要注意什么

独立第三方是硬要求——安全审计必须由独立第三方完成，SRA 建议也找第三方。官方对顾问/审计师的职责写得很明确：具备必要的技能与专长、理解每个工具的影响、执行”黑客测试”前必须取得 ISP 和警方等相关方的书面授权、无论测试成功与否都要记录、报告要反映部门的安全政策与运营需求、发现重大风险或不符合项要立即报告、按需提供支持证据。

数据保护是另一个容易被忽视的点：评估过程中会收集大量配置和敏感数据，必须在规划阶段就安排文件加密工具和可上锁的柜子/房间；评估工具要受控，只由团队内的专家运行，用完立即移除；评估报告在整改前若被未授权访问，本身就是直接威胁，所以过程和最终报告都要严格保密；结束后要归还所有资料，并撤销临时授予审计师的访问权限。

服务前提则包括：提供网络图、操作手册、访问控制清单、安全政策/标准/指南/程序等文档信息；提供网络、防火墙、系统管理等对口人员支持；安排现场走访。

跟进才是价值所在

官方有一句话说得很到位：“风险评估与审计的价值不在建议本身，而在于它们是否被有效落实。” 建议提出后，管理层负责实施；如果决定不实施，就必须承担相应风险并给出充分理由。跟进围绕三个关注点展开：有效性、资质、以及整改的及时性。发现高危项要尽早变更或加固，并准备好回退程序。

对非香港地区有什么参考价值

虽然 SRAA 是香港政府体系的产物，但它的骨架是通用的：风险评估管”风险”，安全审计管”合规”，两者分开做、都要有交付物、都必须闭环验证。这套思路和内地等保测评、ISO/IEC 27001 认证在精神上是相通的——先把资产盘清楚，再算清风险（影响 × 可能性 × 系统分级），然后按风险高低分配整改资源，最后用独立审计确认合规。

如果你所在组织正在搭安全治理框架，SRAA 这套”评估—处置—审计—验证”的迭代闭环，是很值得借鉴的一个模板。尤其那句”风险登记册 + 处置计划 + 验证报告“的三件套，比只交一份渗透测试报告要扎实得多。

安全不是一次测评，而是一个持续迭代的闭环。