路径: 主页 > MISC > 第284页 > MZT027-2011 | 标准编号 | MZ/T 027-2011 (MZ/T027-2011) | | 中文名称 | 自然灾害风险管理基本术语 | | 英文名称 | Basic technical specifications of online fundraising platform for charitable organizations | | 行业 | Chinese Industry Standard (推荐) | | 中标分类 | A22 | | 国际标准分类 | 01.040.01 | | 字数估计 | 13,183 | | 发布日期 | 2011-12-27 | | 实施日期 | 2012-01-01 | | 发布机构 | 民政部 | MZ/T 027-2011: 自然灾害风险管理基本术语
MZ/T 027-2011 英文名称: Basic technical specifications of online fundraising platform for charitable organizations
MZICS 35.241.99A 10/19
中 华 人 民 共 和 国 民 政 行 业 标 准
MZ/T 087-2017
慈善组织互联网公开募捐信息平台
基本技术规范
1 范围
本标准规定了慈善组织互联网公开募捐信息平台在性能、功能、安全、运维等方面的要求。
本标准适用于慈善组织互联网公开募捐信息平台的设计、开发、改造，以及遴选指定、日常运维。
4 基本要求
4.1 合规性要求
互联网公开募捐信息平台（以下简称“平台”）应具有独立法人资格，其中：
--企业应取得通信管理部门核发的、在有效期内的《中华人民共和国增值电信业务经
营许可证》（ICP证)。ICP许可证书上主体名称与平台主体名称应一致。
--事业单位、社会团体、社会服务机构、基金会等非营利性法人，应履行非经营性互
联网信息服务备案，取得ICP备案编号和电子证书，并在有效期内。ICP备案证书上主体名称
与平台主体名称应一致。
--信息系统的安全保护等级不低于《信息安全等级保护管理办法》规定的第三级，并
取得有权机关出具的备案证明。
4.2 响应性要求
4.2.1 每秒请求数
平台每秒成功处理的请求数量应≥300。
4.2.2 响应时间要求
平台平均响应时间应≤0.5秒。
4.3 稳定性要求
平台的系统可用性应≥99.95%，每年宕机时间≤4小时。
4.4 扩展性要求
平台应基于可扩展的系统架构进行设计，可在不改变系统架构的情况下扩展数据内容、业务流程。
4.5 兼容性要求
平台应适合电脑、手机等多终端访问、运行和展示，样式无错乱。
4.6 数据接口要求
平台宜具有数据接口，能按照统一的数据传输标准、数据传输范围将平台数据上传至民
政部门统一的慈善信息公开平台。
4.7 日志记录要求
4.7.1 平台数据的操作应获得相应授权并保留记录，包括：
a) 慈善组织在平台上进行的操作；
b) 互联网公开募捐信息平台运营人员（以下简称“运营人员”）在平台上进行的操作；
c) 互联网公开募捐信息平台用户（以下简称“用户”）在平台上进行的操作。
4.7.2 记录的内容应至少包括：
a) 操作者；
b) 操作时间；
c) 源/目的 IP；
d) 操作对象、操作。
其中，源 IP 应为原始公网 IP（非 CDN 转换后的 IP），时间应准确到秒，并与国际权威时间源保持一致。
5 功能开发要求
5.1 基础功能
5.1.1 公开募捐活动展示
平台应有公开募捐活动汇总展示页面、活动详情页面，页面应无样式错乱。用户能通过
活动名称等关键字在汇总展示页面进行检索。活动详情页面信息应包括：
a) 公开募捐活动在民政部门的备案编号；
b) 活动名称；
c) 募捐目的；
d) 活动进展；
e) 起止日期；
f) 募捐情况；
g) 慈善组织全称、统一社会信用代码及支付账户信息；
h) 受益人（对象）；
i) 活动负责人及联系方式；
j) 活动执行机构全称及联系方式；
k) 募得款物用途；
l) 募捐成本；
m) 剩余财产处理方案；
n) 发票开具方式。
5.1.2 慈善组织展示
通过平台技术，慈善组织相关信息应能在页面展示，包括：
a) 慈善组织全称、统一社会信用代码及支付账户信息；
b) 登记管理机关；
c) 住址及联系方式；
d) 慈善组织登记证书扫描件；
e) 公开募捐资格证书扫描件。
5.1.2 公开募捐活动捐款
平台宜开通在线募捐支付功能并提供技术保障，捐赠资金应直接进入慈善组织的银行账
户或安全的第三方支付账户，不应截留或代为接受捐赠资金。其中，第三方支付账户服务提
供者应具有《非金融机构支付服务管理办法》规定的支付业务许可证。
5.1.4 善款查询
捐赠人可在平台查询历史捐赠记录，包括：
a) 捐赠时间；
b) 参与捐赠的活动及活动进展；
c) 捐赠金额。
5.1.3 社会举报
平台应在公开募捐活动展示页面提供举报功能，接到举报后应与慈善组织、有权机关沟
通，并在5个工作日内通过电话、邮件或短信等方式对举报人进行反馈；经确认举报属实的，
应有技术能力配合有权机关进行处理，包括但不限于暂停募捐活动、下线募捐活动、通知捐款人及相关方等。
5.2 后台管理功能
5.2.1 活动管理
通过平台技术，慈善组织应能对平台上发布的活动进行管理，包括：
a) 创建公开募捐活动，上线前编辑活动；
b) 查看捐赠总额；
c) 便捷地更新活动进展，并反馈给捐赠人。可使用以下方式进行反馈：
--站内信；
--短信；
--应用推送。
5.2.2 捐款管理
通过平台技术，慈善组织应能对平台内捐款信息进行管理，包括：
a) 查看捐款详情；
b) 捐款详情包含：捐赠时间、捐赠人姓名或捐赠人独立标识、捐赠者 ID、支付方式、
支付金额、活动名称、捐赠是否来自境外等；
c) 查看并导出捐赠人申请公益事业捐赠统一票据情况，包括：
--捐赠人名称；
--捐赠项目；
--捐赠金额；
--寄送地址；
--收件人。
5.2.3 捐赠人管理
通过平台技术，慈善组织应能对平台内捐赠人信息进行管理或导出，包括：
a) 查看捐赠人信息，包括：
--捐赠人姓名或平台捐赠人独立标识、是否来自境外；
--捐赠人捐赠情况；
b) 查看每个捐赠人名下对该慈善组织的捐赠总额、捐赠次数；
c) 按照捐赠人姓名或平台捐赠人独立标识、捐赠总额、捐赠次数、捐赠人创建时间
搜索、排序并应能够导出捐赠人列表，包括：
--捐赠人姓名或平台捐赠人独立标识；
--捐赠人捐赠总额；
--捐赠人捐赠次数。
6 安全要求
6.1 物理安全
自建机房的平台应满足GB/T 20271-2006 中6.3.1的有关要求。
6.2 软硬件安全
平台应正确部署软硬件并配置其安全功能，包括：
a)硬件架构中包含防火墙设备；
b)操作系统和业务框架的重大公共漏洞在发现后 6小时内修补；
c)使用的第三方软件保持最新稳定版本。
6.3 数据安全
6.3.1 数据备份
平台应对捐赠信息、捐赠人信息、公开募捐活动信息、慈善组织信息等平台业务数据进行备份，其中：
--增量备份的备份周期应≤1小时，并长期保存；
--完全备份的备份周期应≤24 小时，保存时间应≥2年。
6.3.2 数据恢复
6.3.2.1 平台应建立数据恢复策略，包括：
a) 数据恢复的决策机制；
b) 数据恢复的触发条件；
c)数据恢复节点；
d)数据恢复实施团队；
e) 数据恢复异常情况处理预案。
6.3.2.2 平台应符合数据恢复要求，包括：
a) 若需进行数据恢复，应尽可能减少数据损失；
b) 恢复数据应以增量备份数据为首选，其次为最近时间完全备份数据；
c) 恢复过程可容许中断时长≤30 分钟。
6.4 安全事故及响应
6.4.1 安全事故
安全事故通常包括：
a) 网络接入链路中断或拥塞；
b) 域名系统解析服务异常；
c) 系统瘫痪、遭到入侵或控制、应用服务中断；
d) 用户数据被篡改、丢失；
e) 系统感染恶意代码；
f) 网页篡改、网络仿冒；
g) 其他安全事故。
6.4.2 安全事故响应
6.4.2.1 平台应明确安全事故通知与处理机制，包括：
a) 安全事故类型；
b) 安全事故具体负责人；
c) 安全事故类型及应对方案。
6.4.2.2 若发现恶意攻击，平台应在 15 分钟内予以阻断，30 分钟内解决。
6.4.2.3 若平台在 30 分钟内未能解决安全事故，应及时上报有关部门。
6.4.3 安全事故记录
平台应就发生的安全事故进行记录，其中：
a) 安全事故记录应至少保留 2年，并将处理结果作为定期服务报告的一部分；
b) 安全事故记录的内容至少包含：攻击来源/目的 IP、时间、报警设备、报警级别和内容。
其中，源 IP 应为原始公网 IP（非 CDN 转换后的 IP），时间应准确到秒，且与国际权威时间源一致。
7 运行维护要求
7.1 运行维护团队
平台应有专门技术维护团队，并明确运行维护负责人。
7.2 运行维护人员权限管理
运行维护人员宜分为运行维护经理（主管）、普通运行维护人员。普通运行维护人员对
于系统软硬件以及系统数据进行的任何访问或操作需要经过运行维护经理（主管）授权，访
问或操作完成后应立即收回权限。
7.3 运行维护日志
对于系统软硬件以及系统......
|