ISO/IEC 27002:2022信息安全控制指南：93条控制与属性标签

简介面向信息安全从业者、合规审计与咨询顾问的ISO/IEC 27002:2022中文试译稿针对新版信息安全控制指南的落地理解与体系衔接需求适合在建立、运行或审核信息安全管理体系时对照查阅。压缩包共1个PDF文件约44.41MB内容以标准正文与试译说明为主包含序、引言、范围、术语定义、标准结构及组织控制等章节便于按主题检索控制目标、控制措施与实施要点。已有351人学习下载可作为理解2022版变化、梳理控制项与ISO/IEC 27001映射关系的参考材料。文档还涉及背景和语境、信息安全要求、确定控制、生命周期考虑因素及相关国际标准并附译者说明与版本修订记录有助于读者把握新版标准在网络安全、数据安全治理和管理方面的思路用于内部培训、体系文件修订或控制措施自查时快速定位条款依据。1. 一句话说清 ISO/IEC 27002一份给全组织的「安全控制菜单」装修过房子的人大概都见过两份截然不同的纸一份是施工做法手册防水刷几遍、电线用多粗、瓷砖留多宽的缝全写得明明白白另一份是验收单上面只有合格与不合格两个格子。ISO/IEC 27002 就是信息安全领域的那本做法手册。它不负责发证书也不命令你必须做什么而是把「保护信息」这件听起来很虚的事拆成九十多条能动手落地的控制措施每条都写清楚目的是什么、具体怎么做、在什么条件下才需要考虑。搞懂它的价值不在于背条款而在于建立一套判断力当外部要求、客户问卷、内部审计一起压过来时你能一眼分辨哪些是「达标门槛」哪些是「做法参考」。信息安全管理体系这个词听着唬人落到实处其实就是在回答一个问题——我们打算用哪些手段把哪些风险压到什么程度。27002 给的正是这份手段清单。2. 为什么会有这份文件控制、风险与一个可选武器库2.1 控制到底是什么不是买设备而是把风险压到可接受先把「控制」这个词从玄学里捞出来。它跟「控制欲」没关系指的是任何能改变风险大小的手段一道门禁、一条制度、一次培训、一份备份、一段代码里的输入校验都算。安全领域习惯把风险拆成三个乘在一起的因子威胁会不会来、你这儿有没有可被利用的薄弱点、真出事了损失多大。控制措施的作用点就是中间那个「薄弱点」和最后那个「损失」。拿小区防盗打个比方就很清楚。围墙和门禁是让贼不容易进来这叫预防性控制监控探头和巡逻是让进来的人被看见这叫检测性控制保险公司理赔和备用钥匙是事情已经发生之后把损失兜回来这叫纠正性控制。三类控制缺一不可只装探头不装门等于欢迎光临还全程录像。信息安全的控制也是同一个逻辑备份属于纠正性主要保的是「数据没了还能找回来」日志和活动监视偏检测性解决「出了事能不能还原现场」访问控制、职责分离、安全编码偏预防性尽量别让事情发生。这里有个容易被忽略的点控制是有成本的而且成本不只是钱。多一道审批就多一次等待多一条加密就多一次密钥管理的麻烦。所以真正专业的做法不是把所有控制都堆上去而是先想清楚「我要防的是什么、我愿意为它付出多少不便」再回头挑手段。这就是为什么同一份 27002两家公司勾出来的清单能差出一半——不是谁抄错了是两家的风险账本不一样。2.2 27002 只给「怎么做」不说「你必须做」这份文件最容易被误读的地方是把它当成强制性要求。它更像餐厅菜单菜品、用料、做法、口味说明都写得清清楚楚但点哪几道、点多少取决于你今天几个人吃饭、预算多少、有没有忌口。标准里每条控制都带了「目的」和「实施指南」意思是告诉你这道菜为什么这么配、火候怎么掌握而不是逼你全点。那谁来决定点哪些菜答案是组织自己依据是风险评估的结果和业务的实际需要。做完评估把适用的控制挑出来逐条写下「为什么选它」或者「为什么不选它」这份记录在业内叫适用性声明。它是体系和清单之间的桥梁清单是公共的声明是个性化的。很多团队第一次做体系时最容易翻车的地方就在这儿——直接把九十多条全勾上「适用」看起来很安全实际上等于宣布「我们什么都做」审计时一条证据都拿不出来。提示判断一条控制是否适用问的不是「这条好不好」而是「如果不做这条我们哪个具体风险会变大」。答不上来通常就是不适用或者暂时优先级不够。2.3 从旧版到 2022为什么是重写而不是打补丁2022 年这次更新不是小修小补结构整个换了一副骨架。旧版的写法是把控制挂在若干「控制目标」下面层层嵌套条目又多又碎找一条控制得先想它属于哪个大类。新版干脆砍掉中间层直接按四个主题归类——组织、人员、物理、技术93 条控制平铺在四个篮子裡编号从 5 排到 8。找东西从「回忆目录树」变成「想想这事归谁管」对新手友好得多。更关键的变化是「属性」这套标签的引入。以前想筛出「所有跟检测有关的控制」只能靠人肉通读现在每条控制都贴了五类标签按控制类型、保密性完整性可用性、网络安全概念、运行能力、安全域各打一遍想怎么切就怎么切。这背后是环境变了云服务、远程办公、供应链、隐私保护这些事在旧版里根本没有合适的位置硬塞进去只会越塞越乱。新版还专门补了一批条目像威胁情报、云服务的信息安全、ICT 供应链、数据遮盖、Web 过滤、安全编码光看名字就知道是给这几年新出现的问题准备的。换个角度理解这次重写旧版像一本按章节编排的教科书新版像一张打了多维标签的数据库表。前者适合从头读到尾后者适合按需检索和交叉比对。对做落地的人来说后者的实用性强得多因为你很少需要「通读全部控制」你更需要的是「把跟云端数据有关的条款一次捞干净」。3. 93 条控制怎么排四个主题的骨架3.1 组织控制37 条把安全写进制度和关系里四个主题里最庞大的是组织控制37 条从信息安全策略、角色职责、职责分离一路排到文件化的操作程序。这部分的共同点是它们几乎都不是靠某个技术工具能解决的得靠制度、流程和人之间的约定。放在最前面的 5.1 到 5.4 讲的是「谁来定规矩、谁负责、权力怎么分、管理层要不要真管」等于给整个体系打地基。中间一大段是资产和访问资产清单、可接受使用、资产归还、信息分类、信息标签、信息传递、访问控制、身份管理、鉴别信息、访问权限。这组条目连起来其实是一条完整链路——先知道你有什么清单再定它能怎么用可接受使用与分类最后控制谁能碰它身份、鉴别、权限。很多团队上来就做权限梳理却连资产清单都没有结果权限收得再紧也说不清到底保护了什么。再往后是供应链和云供方关系中的信息安全、供应商协议条款、ICT 供应链、供方服务的监视评审与变更、云服务的信息安全五条连成一片。这是 2022 版特别用力的方向因为现实中的事故越来越多不是自己机房出事而是下游某个服务商出了问题。这一组控制要解决的是「别人的风险怎么变成我的责任」——把安全要求写进合同、定期看对方的实际表现、变更时重新评估。事件管理和连续性占了另一块事件管理的规划准备、事态评估与决策、应对、吸取教训、收集证据、中断期间的信息安全加上 ICT 为业务连续性做好准备。这组条目的顺序本身就很有讲究从「事前准备」到「事中判断」到「事后复盘」最后还单独提了证据收集——因为很多事件最后会走到追责或法律程序现场没保住后面全是空谈。剩下的法律法规、知识产权、记录保护、PII 隐私、独立评审、合规性检查、文件化程序则把体系跟外部世界接上了轨。3.2 人员控制8 条与物理控制14 条这两个主题条目少但最容易被「技术流」团队跳过然后在该出问题的地方出问题。人员控制只有 8 条审查、雇佣条款和条件、意识教育与培训、纪律程序、雇佣关系终止或变更后的责任、保密或不披露协议、远程工作、报告信息安全事态。它覆盖的是一个人在一家公司的完整生命周期——进来之前查背景进来时把安全责任写进合同在岗期间反复教育犯了事有明确的处理程序走人的时候权限和责任一起收回。远程工作单独成条是这几年最实际的变化家里的网络、共享的桌面、孩子在旁边跑来跑去都让「办公环境可控」这个前提不再成立。物理控制 14 条从物理安全周界、物理入口、办公室和设施保护、物理安全监视、抵御环境威胁到安全区域内工作、清桌清屏、设备安置、场外资产、存储介质、支持性设施、布线安全、设备维护、设备的安全作废或再利用。这组条目的逻辑非常朴素门要锁、人要管、纸要收、旧硬盘别直接扔。听起来像常识但常识恰恰最容易失守——会议室白板上的架构图、打印机旁边没人取的合同、报废时没消磁的硬盘都是经典事故现场。清桌清屏这条尤其值得单独拿出来说它的成本几乎为零收益却极直接。3.3 技术控制34 条从终端到代码技术控制 34 条是工程师最亲切的一块。开头几条管身份和权限用户终端设备、特殊访问权、信息访问约束、获取源代码、安全身份认证。特殊访问权这条针对的是管理员账号——权限越大越要单独管、单独审、单独限时。往后是运维日常容量管理、防范恶意软件、技术漏洞管理、配置管理、信息删除、数据遮盖、防止数据泄漏、信息备份、设备冗余、日志、活动监视、时钟同步、特权实用程序、操作系统装软件。这一串基本就是运维值班表上那些事只是标准把它们从「经验」提升成了「可检查的条目」。时钟同步这条常被当成凑数的其实相当关键一旦出事要做时间线还原几台机器的日志时间各差几分钟整个因果链就断了取证的人只能靠猜。日志和活动监视也是同理前者是留证据后者是主动看异常两个不能互相替代。网络与开发占了后半段网络安全、网络服务的安全性、网络隔离、Web 过滤、密码学的使用、安全开发生命周期、应用程序安全要求、安全系统架构和工程原理、安全编码、开发和验收中的安全性测试、外包开发、开发测试生产环境分离、变更管理、测试信息、审计测试期间信息系统的保护。这一段把安全从「机房」推进到了「代码」安全不能只在边界上拦还得在设计和编码阶段就长出来否则后期每修一个洞都要付一次昂贵的返工费。为了看清一条控制到底由哪些字段构成可以把它按标准里的布局抽象成下面这样control: id: 8.13 # 控制编号对应第 8 章技术控制 name: 信息备份 # 控制标题 statement: 按既定的备份策略定期备份信息、软件和系统 # 控制陈述一句话说做什么 purpose: 防止数据丢失 # 目的回答“为什么值得做” attributes: control_type: 纠正性 # 出事之后把数据找回来 cia: [可用性] # 主要保障的是“用得上” capability: 技术 # 靠平台和工具落地 guidance: 备份范围、频率、保存位置、保留期限、恢复演练与加密要求 # 实施指南落到怎么做这份字段示意是把标准 4.3 节的控制布局做了简化不是原文格式。id 和 name 负责定位statement 是一句话的控制要求purpose 解释了它防的是什么attributes 是 2022 版新增的多维标签guidance 才是真正的操作空间——备份多久做一次、存哪儿、留多久、要不要加密、多久做一次恢复演练全在这一栏里由组织自己填。实际使用中最后这一栏填得越具体落地时越不容易糊弄过去只写「定期备份」四个字的通常等于没写。4. 属性2022 版最值得先搞懂的新东西4.1 五种属性分别回答什么问题属性是这版最容易被跳过、也最值得先弄明白的设计。它给每条控制贴上五类标签每类回答一个不同的问题合起来就是一张可以任意维度切片的表。属性回答的问题常见取值控制类型这条控制是在事前、事中还是事后起作用预防性、检测性、纠正性信息安全属性它主要保住哪一样保密性、完整性、可用性网络安全概念它落在安全管理的哪个阶段识别、保护、检测、响应、恢复运行能力它靠什么实现技术、人员、组织安全域它属于哪一类治理范畴治理与生态、保护、防御、韧性与改进先看控制类型。预防性控制是「别让它发生」检测性控制是「发生了要看得见」纠正性控制是「发生了要能收拾」。三条腿缺一条体系就是瘸的。很多组织在预防上砸钱最狠防火墙、加密、权限审批一样不落检测和纠正却近乎空白结果是被入侵了半年才发现发现之后也没有可回滚的备份。信息安全属性这一栏是把控制挂回保密性、完整性、可用性这三根老柱子上。有意思的是很多控制并不只服务一个目标访问控制主要保保密性信息备份主要保可用性而日志和变更管理往往同时服务于完整性和可用性。看清这一点讨论「这条控制值不值得做」时就能直接对上业务语言——业务怕的是数据泄露还是怕系统停摆答案不同优先级就不同。网络安全概念这一栏最有「翻译」价值用的是识别、保护、检测、响应、恢复这套五段式节奏。它把九十多条控制摊到一条时间线上出事之前你在识别资产和风险出事当下你在保护、检测、响应事后你在恢复。安全域那一栏则更偏治理视角把控制按治理与生态、保护、防御、韧性与改进归堆方便管理层看「我们在哪个层面投入不足」。运行能力最简单靠技术、靠人、还是靠制度。4.2 一个例子给「信息备份」贴满标签拿 8.13 信息备份走一遍。控制类型是纠正性因为它不阻止数据丢只在丢了之后把数据找回来信息安全属性主要落在可用性上顺带也能防篡改前提是备份介质本身受保护网络安全概念这一栏跨了保护和恢复两段运行能力偏技术但备份策略的制定和演练的组织又离不开人安全域大致归在韧性与改进。五个标签贴完这条控制在整个体系里的位置就清楚了它是一个兜底角色位置靠后但一旦缺失前面所有预防措施的价值都会打折。再看一条反差大的6.3 信息安全意识、教育和培训。控制类型是预防性信息安全属性三项都沾一点网络安全概念落在保护段运行能力明确是人员安全域偏治理。把这两条并排放你会发现它们的标签几乎不重叠——这正是属性的用处它让「一条控制和一个组织」之间的匹配关系变得可计算、可讨论。4.3 属性的用处与误用筛选不等于取舍属性最直接的用处是筛选。想找「所有检测性控制」来补监控短板一筛就出来了想找「所有靠人实现的控制」来评估培训预算也是一筛就出来想跟别的管理框架对齐把网络安全概念那一栏当翻译层两边的词就能对上话。对写材料的人来说这比按章节顺序硬读省太多力气。但属性有两个坑。第一个坑是把标签当结论一条控制被标成「预防性」不代表它只做预防标签是主要倾向不是全部分工。第二个坑更常见——以为贴了标签就等于做了取舍。属性只是描述工具它不告诉你哪条该做哪条不该做。真正决定取舍的仍然是风险评估你的资产值多少、威胁有多现实、现有薄弱点在哪。见过不少团队把属性矩阵做得漂漂亮亮一到要说明「为什么这条不适用」就哑口无言问题就出在把检索工具当成了决策工具。注意属性的取值是标准方给的通用分类落到具体组织时同一条控制可能因为业务场景不同而落在不同侧重上。标签可以照抄理由必须自己写。5. 常见易混与误区这几组概念最容易搞反5.1 27002 和 27001做法手册与达标要求易混点在于两个编号长得像、名字也像很多人以为是一份文件的两个版本。为什么会混它们确实是一对搭档通常一起出现讲的内容也高度相关。怎么区分27001 是「要求」写的是你必须建立并运行一套管理体系包括风险评估、风险处置、适用性声明、内部审核、管理评审这些动作是可以被认证的标准27002 是「指南」写的是具体有哪些控制手段、每条怎么做本身不构成认证依据。一句话记27001 考你有没有体系和证据27002 教你怎么选手段。做体系的人两本都要翻但翻的目的完全不同——一本是对表一本是查菜谱。5.2 控制目标退场目标和措施不是一回事旧版有一个中间层叫「控制目标」每条控制都挂在一个目标下比如「访问控制的目标是限制对信息和设施的访问」。2022 版删掉了这一层直接给控制条目改用属性和主题来组织。易混点在于很多人还在用老话术把某条控制说成「控制目标」。为什么会混旧文档、旧培训材料、旧模板里全是这个说法习惯很难改。怎么区分目标是「我要达到什么状态」措施是「我用什么手段达到」前者是判断标准后者是动作。现在标准里每条控制自带一个「目的」字段功能上接替了当年控制目标的位置但它挂在具体控制下面不再单独成层。写材料时把两者混用最直接的后果是适用性声明里列的全是目标而不是可执行的动作审起来没法验证。5.3 通用菜单与专项菜谱别拿 27002 当万能答案易混点是把 27002 当成安全领域的唯一参考遇到云、隐私、工业场景也硬套。为什么会混它覆盖面确实广四个主题 93 条看着很全容易产生「一本通」的错觉。怎么区分27002 是通用控制清单具体领域通常有更细的专项标准云服务、隐私保护、行业特定场景各有各的补充要求。正确姿势是先拿 27002 搭骨架再按业务所处领域补专项条款而不是反过来。就像装修做法手册再全也不会有「手术室净化工程」的施工细节那是另一本规范的事。5.4 拿到指南不等于合规更不等于安全易混点是把「有这份文件」当成「问题解决了」。为什么会混标准本身有权威感中文版一到手心理上就先踏实了一半。怎么区分合规是证据问题安全是效果问题两者都不是文档能自动产生的。真正决定成败的是三件事——有没有做风险评估、有没有把选中的控制落成可检查的动作、有没有留下能证明它一直在运行的记录。见过太多团队把标准打印出来放进文件夹权限该共享还共享离职账号该留着还留着。文档的价值在于统一语言、提供清单、支撑判断它不会替任何人值班。6. 什么时候该翻它什么时候别指望它判断标准其实很简单当你需要「选手段」的时候它有用当你需要「拿结论」的时候它帮不上忙。场景建议第一次搭信息安全管理体系不知道从哪儿下手该翻。先按四个主题过一遍建立全景认知做完风险评估要把风险处置落成具体动作该翻。逐条对照目的和指南挑出适用的要写适用性声明需要说明「为什么选/不选」该翻。用控制陈述和目的做论证依据要给控制措施排优先级、找监控盲区该翻。用属性筛选比通读高效得多要拿认证证书别指望。认证依据是要求类标准这份只是参考想知道某台防火墙具体怎么配、某参数填多少别指望。它给的是做什么和为什么不给命令和阈值遇到单一技术问题比如某个漏洞怎么修别指望。那是漏洞管理流程和厂商公告的事想拿它当法律依据去追责别指望。标准不是法规合同和制度才是抓手举个具体例子。某公司三十来人第一次认真做体系负责人一开始的想法是把 93 条全勾上觉得这样最保险。真到写证据的时候傻了一半条目根本找不到对应动作比如 ICT 供应链那几条公司压根没有像样的供应商管理流程再比如物理安全监视办公区是合租的连门口摄像头都不归自己管。后来改成先做资产清单和一轮务实的风险评估从 93 条里挑出四十来条真正对症的每条都写清楚「选的理由」或者「暂不适用的理由」剩下的列入后续计划。工作量少了一半审计时反而顺利——因为每一条都能指出证据在哪个文件夹。我自己的血泪经验是永远不要在没做风险评估之前打开这份清单开始勾选。有那么一次我在项目初期图省事先把控制清单拉了一遍勾得挺齐等到风险评估做完发现真正的大风险在数据导出和外包开发上而那两块当时只勾了两条最泛的。返工的时候才明白清单是给风险配药的顺序反了配出来的东西看着齐全实际上没打到点上。从那以后我每次做适用性声明都强制先过一遍风险清单再翻控制条目勾一条写一条理由写不出理由的就先空着。希望帮到你。本文还有配套的精品资源点击获取