信息安全事件响应处理手册（标准版）

信息安全事件响应处理手册（标准版）第1章事件响应概述1.1事件响应定义与目标事件响应（IncidentResponse）是指组织在遭受信息安全事件发生后，采取一系列有序的措施，以最小化损失、减少影响、保护业务连续性及恢复系统正常运行的过程。这一过程通常遵循预先制定的策略与流程，旨在实现事件的快速识别、分析、遏制、处置、恢复与事后总结。根据ISO27001信息安全管理体系标准，事件响应的目标包括：快速识别事件、控制事件影响、防止事件扩大、保障业务连续性、保护组织资产及满足合规要求。事件响应的实施需结合组织的业务需求、技术架构及安全策略，确保响应措施与组织的总体信息安全目标一致。有研究指出，事件响应的效率直接影响组织的声誉、经济损失及法律风险，因此需建立完善的响应机制与流程。事件响应的目标不仅是解决当前问题，还需通过事后分析优化响应流程，提升组织的抗风险能力。1.2事件响应流程与阶段事件响应通常分为五个阶段：事件识别（IncidentIdentification）、事件分析（IncidentAnalysis）、事件遏制（IncidentContainment）、事件消除（IncidentEradication）和事件总结（IncidentSummary）。根据NIST（美国国家标准与技术研究院）的《信息安全事件处理框架》，事件响应流程应包括事件发现、分类、报告、响应、恢复与事后复盘等环节。在事件识别阶段，应通过监控系统、日志分析及用户报告等方式，快速定位事件来源与影响范围。事件分析阶段需确定事件类型、影响程度及潜在风险，为后续响应提供依据。事件遏制阶段的核心是防止事件进一步扩散，如隔离受影响系统、阻断网络攻击路径等。1.3事件响应团队组织与职责事件响应团队通常包括首席信息官（CIO）、信息安全经理、技术团队、法律合规人员及外部顾问等角色。团队职责应明确：CIO负责总体协调与决策，信息安全经理负责技术响应与策略制定，技术团队负责具体操作与系统恢复，法律团队负责合规与取证。根据ISO27001标准，事件响应团队需具备跨部门协作能力，确保响应过程高效、有序。有研究表明，团队成员的分工与职责明确，可显著提升事件响应效率与成功率。事件响应团队需定期进行演练与培训，确保团队成员熟悉流程与工具，提升应急处理能力。1.4事件响应工具与技术事件响应工具包括日志分析系统（如ELKStack）、网络监控工具（如Nmap、Wireshark）、终端检测与响应（TDR）系统、事件管理平台（如IBMQRadar）等。日志分析系统可实现对系统日志、应用日志及网络流量的实时监控与分析，帮助识别异常行为。网络监控工具可检测异常流量、端口开放、服务异常等，辅助事件发现与分析。终端检测与响应系统可识别未授权访问、恶意软件感染等行为，提供即时响应与隔离机制。事件管理平台可整合各类工具，实现事件的统一管理、报告、跟踪与分析，提升响应效率。1.5事件响应的法律法规与标准事件响应需符合国家及行业相关法律法规，如《中华人民共和国网络安全法》《个人信息保护法》及《信息安全技术个人信息安全规范》（GB/T35273-2020）。根据ISO/IEC27001标准，组织需建立信息安全管理体系，确保事件响应符合合规要求。事件响应需遵循《信息安全事件分级标准》（GB/Z20986-2019），明确事件等级与响应级别。有研究指出，事件响应需结合行业特点与法律法规，确保响应措施合法合规，避免法律风险。事件响应的法律依据不仅包括国内法规，还需参考国际标准如ISO27001、NISTIR（信息安全管理框架）等，确保响应的国际兼容性。第2章事件识别与分类2.1事件识别方法与工具事件识别主要基于系统日志、网络流量、用户行为、应用日志及安全设备告警等多源数据，采用基于规则的检测方法与机器学习模型相结合的方式，以实现对潜在安全事件的早期发现。常用工具包括SIEM（安全信息与事件管理）系统、入侵检测系统（IDS）、防火墙、终端检测与响应（EDR）工具及漏洞扫描器等，这些工具能够实时监控网络环境，识别异常行为。事件识别需结合威胁情报和已知漏洞库，通过关联分析技术，将孤立的事件转化为具有关联性的安全事件，提高识别准确率。依据ISO/IEC27001标准，事件识别应遵循“最小化影响”原则，确保在事件发生后第一时间进行识别，避免信息滞后导致的处理延误。事件识别过程中需记录事件发生的时间、地点、影响范围及初步处理措施，为后续分析提供基础数据支持。2.2事件分类标准与分类流程事件分类通常采用基于风险等级、影响范围、发生频率及威胁类型等维度进行分类，常见分类方法包括基于风险的分类（Risk-BasedClassification）和基于影响的分类（Impact-BasedClassification）。依据ISO/IEC27005标准，事件应按照其严重性、影响程度及恢复难度分为多个级别，如“低”、“中”、“高”、“紧急”等，以指导后续处理资源的分配。分类流程一般包括事件初步分类、交叉验证、最终分类及分类结果存档，确保分类的客观性与一致性。事件分类需结合组织的业务系统架构、安全策略及历史事件数据，通过分类矩阵或规则引擎实现自动化分类。事件分类后应形成分类报告，明确事件类型、影响范围、风险等级及建议处理措施，为后续响应提供依据。2.3事件优先级评估与处理顺序事件优先级评估通常基于事件的影响范围、威胁等级、发生频率及恢复难度，采用定量与定性相结合的方法进行评估。依据NISTSP800-88标准，事件优先级可划分为“紧急”、“高”、“中”、“低”四个等级，其中“紧急”事件需在1小时内响应，而“低”事件可安排在日常处理流程中。事件处理顺序遵循“先处理高优先级，后处理低优先级”的原则，确保关键系统和数据的安全性不受影响。事件处理过程中需明确责任人及处理时限，确保各环节有序进行，避免资源浪费和责任推诿。事件优先级评估应结合业务连续性管理（BCM）和应急响应计划，确保处理顺序与组织的业务需求一致。2.4事件报告与信息收集事件报告应遵循统一格式，包含事件时间、类型、影响范围、责任人、处理进展及建议等信息，确保信息透明且易于追踪。事件信息收集需采用主动采集与被动采集相结合的方式，包括日志采集、网络流量抓包、终端行为分析等，确保信息的全面性和准确性。事件报告应基于组织的事件管理流程，遵循“报告-分析-响应-恢复”四阶段模型，确保信息传递的及时性和有效性。事件信息收集过程中需注意数据隐私和保密性，避免敏感信息泄露，符合GDPR及《个人信息保护法》等相关法规要求。事件报告应通过内部系统或外部平台进行，确保信息在组织内部及外部相关方之间有效传递，提升协同响应效率。2.5事件分类的注意事项与要求事件分类需避免主观臆断，应基于客观数据和已知威胁情报进行判断，防止误判或漏判。事件分类应保持一致性，确保不同部门和人员在分类标准和流程上达成共识，避免分类标准不统一导致的处理混乱。事件分类后应定期进行复审和优化，根据实际运行情况调整分类标准，确保其适应组织的安全环境变化。事件分类需与事件响应计划、应急预案及恢复策略相衔接，确保分类结果能够有效指导后续处理措施。事件分类过程中应记录分类依据及过程，形成分类日志，便于后续审计和追溯。第3章事件分析与评估3.1事件数据收集与分析方法事件数据收集应遵循“全面、及时、准确”的原则，采用日志采集、网络流量监控、终端日志、用户行为分析等手段，确保覆盖所有可能的攻击路径和系统异常。数据收集需结合结构化日志（如Syslog）与非结构化日志（如用户操作日志、网络流量日志），通过日志分析工具（如ELKStack、Splunk）进行实时处理与分析。数据分析应采用基于规则的检测与基于机器学习的预测相结合的方式，结合威胁情报（ThreatIntelligence）与已知攻击模式，提升事件识别的准确率。事件数据应按时间、类型、来源、影响范围等维度分类存储，并定期进行数据清洗与归档，确保数据的可追溯性与可验证性。事件数据分析需结合定量与定性方法，如使用统计分析（如异常值检测、聚类分析）与定性分析（如事件影响评估、风险等级划分）进行综合判断。3.2事件影响评估与分析事件影响评估应从业务连续性、数据完整性、系统可用性、安全合规性等方面展开，采用影响评估模型（如NISTIR800-145）进行量化分析。事件对业务的影响可量化为服务中断时间、数据泄露量、系统损毁程度等指标，通过影响矩阵（ImpactMatrix）进行优先级排序。事件影响评估需结合业务影响分析（BusinessImpactAnalysis,BIA）与风险评估（RiskAssessment），评估事件对组织战略、运营、财务等目标的潜在威胁。事件影响评估应考虑不同场景下的影响差异，如内部系统与外部系统的差异、关键业务系统与非关键系统的差异。事件影响评估结果应形成报告，供管理层决策与后续应急响应策略制定提供依据。3.3事件根源分析与溯源事件根源分析应采用“事件溯源”（Event溯源）方法，结合日志分析、网络流量分析、终端行为分析等手段，追溯事件发生的起因。事件根源通常涉及攻击者行为、系统漏洞、配置错误、第三方服务异常等，需结合威胁情报（ThreatIntelligence）与攻击路径分析（AttackPathAnalysis）进行判断。事件溯源应考虑攻击者的动机、技术手段、攻击方式及攻击目标，通过攻击图（AttackGraph）进行可视化分析，明确攻击路径与攻击者行为模式。事件根源分析需结合安全事件分类（如APT攻击、DDoS攻击、数据泄露等），结合安全事件分类标准（如ISO/IEC27001）进行分类与归因。事件根源分析应形成溯源报告，明确攻击者、攻击手段、攻击路径及系统漏洞，为后续防御策略提供依据。3.4事件影响范围评估事件影响范围评估应从系统、网络、数据、用户、业务等多维度展开，采用影响范围评估模型（如NISTIR800-145）进行量化分析。事件影响范围可包括系统宕机、数据丢失、服务中断、用户身份泄露等，需结合系统拓扑结构、网络边界、数据存储位置等进行评估。事件影响范围评估应考虑事件的传播性与扩散性，如横向越权访问、恶意软件传播、攻击链传播等，评估事件对组织整体安全的威胁程度。事件影响范围评估需结合业务影响分析（BIA）与安全影响评估（SIA），评估事件对业务连续性、数据安全、合规性等的影响。事件影响范围评估结果应形成报告，供应急响应团队制定后续处置方案与恢复计划提供依据。3.5事件影响的量化与定性分析事件影响的量化分析可通过统计方法（如均值、方差、标准差）与定量指标（如服务中断时间、数据泄露量、系统损毁程度）进行评估。事件影响的定性分析需结合定性评估模型（如风险矩阵、威胁等级划分）进行判断，评估事件对组织安全、业务、合规等的潜在威胁。事件影响的量化与定性分析应结合定量与定性指标，形成综合评估报告，为事件分级、应急响应策略制定与后续改进提供依据。事件影响分析需考虑事件的持续时间、影响范围、影响深度、影响广度等关键指标，确保评估的全面性与准确性。事件影响分析结果应形成详细的报告，供管理层决策、安全团队改进策略、审计部门合规审查等提供依据。第4章事件遏制与控制4.1事件隔离与阻断措施事件隔离是指通过技术手段将受感染的系统或网络段与正常业务系统进行物理或逻辑隔离，防止攻击扩散。根据ISO/IEC27001标准，隔离措施应包括网络分段、防火墙配置、访问控制列表（ACL）等，以切断攻击路径。事件阻断应依据《信息安全技术信息安全事件分类分级指南》（GB/Z20986-2021）进行，通过关闭异常端口、限制访问权限、断开网络连接等方式，防止攻击者进一步渗透或数据泄露。在事件发生后，应立即启动应急响应预案，使用网络隔离设备（如隔离网闸、隔离网关）将受影响的子网与外部网络隔离开，避免攻击者利用内部网络继续扩散。隔离措施需在事件发生后24小时内完成，并根据事件严重程度动态调整隔离范围，确保不影响正常业务运行。根据2021年某大型金融企业信息安全事件案例，隔离措施可有效阻止攻击者从内部网络向外扩散，减少数据泄露风险。4.2事件影响范围控制事件影响范围控制应遵循《信息安全事件分级标准》（GB/Z20986-2021），根据事件类型、影响范围和业务影响程度，确定控制措施的优先级。事件影响范围控制应通过监控系统实时追踪攻击扩散情况，利用日志分析、流量监控等手段识别受影响的系统和用户，避免扩大影响。对于关键业务系统，应采取“最小权限”原则，限制受影响系统的访问权限，防止攻击者进一步操控或破坏。控制措施应包括临时关闭非必要服务、限制用户访问、限制网络访问等，确保受影响系统在可控范围内运行。根据2019年某政府机构事件案例，及时控制影响范围可有效减少业务中断时间，降低损失。4.3事件数据备份与恢复事件数据备份应遵循《信息安全技术数据备份与恢复指南》（GB/T22239-2019），确保数据在事件发生后能够及时、完整地恢复。备份策略应包括全量备份、增量备份、差异备份等，根据数据重要性、业务连续性要求选择合适的备份频率和方式。数据恢复应优先恢复关键业务系统，确保业务连续性，同时防止数据恢复过程中再次发生安全事件。恢复过程应进行验证，确保数据完整性与一致性，防止因恢复不当导致二次泄露或系统故障。根据2020年某电商平台事件案例，有效的备份与恢复机制可将数据恢复时间缩短至数小时，降低业务中断风险。4.4事件应急措施实施事件应急措施实施应遵循《信息安全事件应急响应指南》（GB/Z20986-2021），根据事件等级启动相应的应急响应级别。应急措施包括：人员疏散、系统停用、数据加密、监控预警等，确保事件处理过程中的安全与有序。应急响应团队应定期进行演练，确保在事件发生时能够快速响应、有效处置。应急措施实施过程中，应保持与外部监管部门、技术支持单位的沟通，确保信息同步与协作。根据2018年某医疗系统事件案例，及时实施应急措施可有效控制事件影响，避免大面积系统崩溃。4.5事件控制的监控与反馈事件控制的监控应通过实时监控系统、日志审计、网络流量分析等手段，持续跟踪事件处理进展。监控应包括事件发生后的持续监控、处理过程中的状态跟踪、恢复后的验证等，确保事件处理的透明与可控。应建立事件控制的反馈机制，将事件处理过程中的问题、风险和经验纳入总结，优化后续应对策略。监控与反馈应与事件分级管理相结合，确保信息及时传递、问题及时发现、措施及时调整。根据2022年某政府机构事件案例，完善的监控与反馈机制有助于提升事件响应效率，减少后续影响。第5章事件修复与恢复5.1事件修复策略与方案事件修复策略应依据《信息安全事件等级保护基本要求》（GB/T22239-2019）中的分类标准，结合事件类型、影响范围及恢复优先级，制定针对性的修复方案。修复策略需遵循“最小化影响”原则，优先恢复关键业务系统，确保数据完整性与业务连续性。修复方案应包含技术措施、管理措施及沟通机制，确保修复过程可控、可追溯。依据《信息安全技术事件处理规范》（GB/T20984-2007），修复过程需明确责任分工、时间节点及验收标准。修复方案应结合历史类似事件的处理经验，参考ISO27005信息安全管理体系标准，确保修复过程科学合理。5.2事件修复过程与步骤事件修复应按照“识别—隔离—修复—验证”流程进行，确保每个阶段均有明确的操作指引。修复前需对事件影响范围进行量化评估，使用定量分析方法（如影响图、风险矩阵）确定修复优先级。修复过程中应采用“分阶段修复”策略，先处理核心系统，再逐步恢复辅助系统，避免资源浪费。修复后需进行日志分析与系统状态检查，确保所有问题已彻底解决，无遗留风险。修复过程中应建立临时应急机制，确保业务连续性，避免因修复延迟导致业务中断。5.3事件修复后的验证与测试修复后需进行系统功能验证，确保修复内容符合原设计要求，避免因修复导致系统功能异常。验证应包括功能测试、性能测试及安全测试，使用自动化测试工具（如Selenium、Postman）进行效率评估。验证结果需形成书面报告，记录修复过程、测试结果及问题处理情况，确保可追溯性。验证后需进行用户反馈收集，通过问卷或访谈了解修复效果是否满足业务需求。验证通过后，方可进入下一阶段的恢复与监控，确保系统稳定运行。5.4事件恢复的监控与评估事件恢复后应建立监控机制，实时跟踪系统运行状态，使用监控工具（如Zabbix、Nagios）进行性能监控。监控内容应包括系统响应时间、资源利用率、异常告警等关键指标，确保系统恢复正常运行。建立恢复评估模型，结合《信息安全事件处理指南》（GB/T20984-2007）中的评估标准，量化恢复效果。评估应包括恢复效率、成本效益及风险控制效果，确保恢复过程符合组织安全策略。恢复评估后，需形成恢复报告，总结经验教训，为未来事件处理提供参考。5.5事件修复后的总结与复盘修复后应进行事件复盘，分析事件发生原因、修复过程及改进措施，形成复盘报告。复盘报告应包含事件背景、影响范围、修复过程、问题根源及改进建议，确保问题闭环管理。复盘应结合《信息安全事件管理规范》（GB/T20984-2007）中的复盘要求，确保内容全面、有据可依。复盘结果应反馈至相关部门，推动制度优化与流程改进，提升组织应对能力。复盘后需进行培训与知识传递，确保相关人员掌握事件处理经验，提升整体应急响应水平。第6章事件报告与沟通6.1事件报告的格式与内容事件报告应遵循统一的结构化格式，包括事件概述、影响范围、发生时间、责任部门、应急处置措施、已采取的修复措施、当前状态及后续建议等关键信息，确保信息完整且便于快速理解。根据《信息安全事件分类分级指南》（GB/T22239-2019），事件报告需明确事件类型、等级、发生时间、影响资产、受影响用户范围及事件影响程度，以支持后续的应急响应与恢复工作。事件报告应使用标准化的模板，如《信息安全事件报告模板》（ISO/IEC27001标准），确保信息的一致性与可追溯性，便于跨部门协作与审计追溯。报告中应包含事件发生的具体时间点、责任人、处理流程、已修复状态及潜在风险，确保事件处理的透明度与可验证性。事件报告应由事件发生部门负责人签发，确保责任明确，同时需在内部系统中进行记录，便于后续审计与复盘。6.2事件报告的发布与传递事件报告的发布应遵循分级管理原则，根据事件等级确定报告的发布范围与方式，避免信息过载或信息泄露。事件报告可通过内部系统（如信息安全事件管理系统）或邮件、公告、会议等方式发布，确保不同层级的人员及时获取信息。对于重大事件，应通过公司内部通报、新闻发言人机制或第三方媒体发布，确保公众知情权与信息安全的平衡。事件报告的传递需遵循保密原则，确保信息在传递过程中不被篡改或泄露，避免引发二次风险。事件报告的传递应有明确的记录与归档，确保可追溯性，便于后续调查与责任认定。6.3事件报告的保密与合规要求事件报告应严格遵守数据保密原则，涉及敏感信息的报告需采用加密传输与权限控制，防止信息泄露。事件报告的保密要求应符合《个人信息保护法》及《网络安全法》的相关规定，确保信息处理符合法律规范。事件报告的保密期限应根据事件的严重性与影响范围确定，一般不超过事件处理完成后的7天，特殊情况可延长。事件报告的发布需经过审批流程，确保内容合法合规，避免因信息不实引发法律风险。事件报告的保密措施应包括访问控制、数据脱敏、审计日志等，确保信息在传递与存储过程中的安全性。6.4事件沟通的渠道与方式事件沟通应采用多渠道方式，包括内部系统、邮件、电话、会议、公告、第三方平台等，确保信息覆盖全面。事件沟通应遵循“分级响应、分级沟通”原则，重大事件由公司高层负责，一般事件由相关部门负责人沟通。事件沟通应注重时效性与准确性，确保信息传递及时、清晰，避免因沟通不畅导致应急响应延误。事件沟通应结合公司内部沟通机制，如《信息安全事件沟通流程》，确保信息传递的规范性与一致性。事件沟通应定期进行复盘与优化，根据实际效果调整沟通策略，提升整体应急响应效率。6.5事件报告的后续跟进与反馈事件报告发布后，应建立跟踪机制，确保事件处理措施落实到位，并定期汇报处理进展。事件处理完成后，应形成《事件处理总结报告》，包括处理过程、问题根源、改进措施及后续预防建议。事件反馈应通过内部系统或会议形式向相关部门通报，确保信息闭环，避免问题重复发生。事件反馈应结合《信息安全事件管理流程》（ISO27001标准），确保反馈机制的系统性与可操作性。事件反馈应纳入年度信息安全评估体系，作为改进信息安全策略的重要依据。第7章事件复盘与改进7.1事件复盘的流程与方法事件复盘应遵循“事前分析、事中复盘、事后总结”的三阶段流程，依据ISO/IEC27001信息安全管理体系标准，结合事件发生前后的时间线进行系统性回顾。采用“5W2H”分析法（Who、What、When、Where、Why、How、HowMuch），结合事件影响范围、损失程度、责任归属等关键要素，明确事件的起因、过程及后果。事件复盘应结合事件发生前的预防措施和事件发生后的应急响应流程，评估预案的有效性与响应速度，确保后续处理更加高效。采用“事件树分析法”（EventTreeAnalysis,ETA）对事件可能的后续影响进行预测，识别潜在风险点，为后续改进提供依据。事件复盘应由信息安全事件响应团队、管理层及相关部门共同参与，形成书面复盘报告，作为后续改进的重要参考依据。7.2事件复盘的分析与总结通过事件影响评估模型（如NIST事件影响评估模型）量化事件对业务连续性、数据完整性、系统可用性等方面的影响，明确事件等级与严重性。结合事件发生前的漏洞扫描、日志审计、安全监测等数据，分析事件发生的原因，判断是人为失误、系统漏洞、外部攻击还是其他因素导致。事件复盘应结合ISO27005信息安全事件管理指南，对事件响应过程中的沟通机制、资源调配、决策依据等进行评估，找出优化空间。通过事件复盘报告，识别事件响应中的关键节点（如事件发现、上报、分析、处置、恢复），并提出改进建议，提升整体事件响应效率。事件复盘应形成标准化的复盘报告模板，包括事件概述、影响分析、原因归因、改进建议等部分，确保复盘结果可追溯、可复用。7.3事件改进措施的制定与实施根据事件复盘结果，制定针对性的改进措施，包括技术加固、流程优化、人员培训、制度修订等，确保整改措施符合ISO27001标准要求。改进措施应基于事件发生的原因，例如若事件因系统漏洞导致，应制定定期漏洞扫描与修复计划，落实“零漏洞”目标。改进措施需明确责任人、时间节点、验收标准，确保措施落地执行，避免“纸上谈兵”。采用“PDCA”循环（计划-执行-检查-处理）对改进措施进行跟踪，确保措施有效实施并持续优化。改进措施应纳入信息安全事件管理流程，作为后续事件响应的参考依据，形成闭环管理。7.4事件改进的跟踪与评估建立事件改进跟踪机制，通过定期检查、审计、评估等方式，确保改进措施按计划执行并取得预期效果。采用“事件改进效果评估模型”（如NIST事件后评估模型），对改进措施的实施效果进行量化评估，包括事件发生频率、响应时间、恢复效率等指标。通过第三方审计或内部评估，验证改进措施是否符合组织信息安全战略目标，确保改进措施与业务需求一致。建立改进措施的反馈机制，收集相关人员的意见和建议，持续优化改进方案。改进措施的评估结果应形成书面报告，作为组织信息安全管理体系改进的重要依据。7.5事件复盘的文档记录与归档事件复盘应形成标准化的复盘报告，包括事件概述、分析过程、原因归因、改进措施、评估结果等，确保内容完整、可追溯。复盘报告应按照信息安全事件管理流程规范，归档于组织的信息安全档案系统，便于后续查阅与审计。事件复盘文档应包含事件时间戳、责任人、复盘人、复盘日期等关键信息，确保文档的可验证性与完整性。事件复盘文档应定期更新，根据事件发生频率、影响范围及改进效果进行归档管理，形成历史记录。事件复盘文档应作为组织信息安全管理体系的参考资料，用于培训、审计、合规性检查等目的。第8章附录与参考文献8.1附录A事件响应工具清单本附录列出了在事件响应过程中常用的工具和系统，包括但不限于SIEM（安全信息与事件管理）、EDR（端点检测与响应）、SIEM平台、日志分析工具、网络流量分析工具、终端防护软件等。这些工具能够帮助组织实时监控、检测和响应潜在的网络安全事件。例如，Splunk、IBMQRadar、MicrosoftSentinel等主流SIEM平台，均具备事件分类、趋势分析、威胁情报集成等功能，是事件响应流程中的关键支撑系统。事件响应工具需具备高可用性、可扩展性及兼容性，以适应不同规模和复