饿了么开放平台开放平台应用安全实施指南

指南版本号：v1.0
指南版本时间：2019年08月16日

1. 前言

为了更好的促进饿了么生态的良性发展，保障生态内用户在使用过程中的数据安全，提升开放平台合作伙伴提供服务的安全性，特制定此实施指南。
在饿了么中所有开放平台中的合作伙伴企业建议部署在零售云中，通过该文档进行安全管理。未进入零售云的合作伙伴，请参照实施指南进行应用管理。

2. 适用范围

本规范规定了饿了么生态内的合作伙伴在创建、部署、实施、运维饿了么平台服务的过程中需要遵守的数据安全行为准则，适用于生态内合作伙伴的所有相关人员。

3. 概念和术语

开放平台：指由饿了么所拥有并且经营，提供给开发者使用的网站及相关页面，简称“开放平台”。
开发者：指按照开放平台流程经注册、登录，通过技术文档进行软件开发的自然人、法人或者组织。开发者通过开放平台提供的技术文档进行软件开发，服务自身或者其他客户。
应用： 指由开发者通过开放平台提供的技术文档所开发的应用程序或者软件服务。
服务商（ISV）：指您，按照开放平台流程经有效注册、申请后，通过开放平台进行应用开发或完善并提供咨询、操作等有偿服务的法人或其他组织。
零售云：给开发者的应用提供了一个稳定、安全的环境，其中包括了云主机的安全性、RDS的安全性以及数据集成中的安全性。
零售云内调用：指零售云内的系统和应用发起的对开放平台API的使用行为，环境包括零售云的云主机、应用运行引擎和托管主机等，以开发者发起调用的IP地址是否属于零售云认定的IP范围为准。
御城河：御城河基于阿里海量的基础数据和强大的数据分析能力，利用行业领先的风险检测模型，为生态中的商家、服务商、物流伙伴提供数据风险的预防和发现服务，实时检测和识别设备、账号、应用、系统中的异常数据访问行为并进行适当处置。

4. 规范性引用文件

4.1 《中华人民共和国网络安全法》，2016年11月7日；
4.2 《信息系统安全等级保护基本要求》，国标GB/T 22239 – 2008，2008年6月；
4.3 《移动智能终端安全能力技术要求》，工信部，YD/T 2407-2013，2013年4月；
4.4 《信息系统通用安全技术要求》，GBT 20271-2006，2006年5月；
4.5 《电子商务基本术语》，GB/T 18811；
4.6 《信息安全技术 术语》，GB/T 25069-2010；
4.7 《信息技术 安全技术 信息安全事件管理指南》，GB/Z 20985-2007；
4.8 《信息安全技术 信息安全事件分类分级指南》，GB/Z 20986-2007；
4.9 《信息技术 系统安全工程 能力成熟度模型》，GBT 20261-2006；
4.10《数据安全管理条例》，2019年5月28日

5. 生态数据安全管理规范

饿了么对生态内的数据安全实施严格的管理标准，不仅对数据全生命周期进行安全管理，还对应用运行的基础设施、服务部署实施人员的操作进行明确的规范。饿了么会定期对生态内的数据安全状况进行审计，对发现的任何数据安全风险都会进行及时治理，对于任何违规问题都会给予必要的处罚。
本章列出了评估审计中重点考核的领域，评估过程会根据具体的业务情况调整评估内容。

5.1 基础设施安全

任何在饿了么平台提供服务的业务都需要确保支撑业务的基础设施本身安全、可靠、安全、合规，能够持续不间断的提供安全、高可用、高可信的服务，并且需要有专门的运维团队随时保障基础设施的稳定、高效运行。ISV须部署在饿了么零售云上，其他合作伙伴建议使用饿了么零售云或饿了么零售云同等服务能力的服务提供商。

5.2 主机系统安全

业务运行的主机系统需要具备必要的安全能力，包括但不限于病毒扫描、漏洞扫描、入侵检测、系统恶意行为、非法注入等防护能力。如果业务运行过程中需要对数据进行持久化存储，需要确保数据管理系统也要具备同样的安全防护能力，数据库相关的安全要求参见数据库安全部分。
参照：第6、7章节

5.3 数据库安全

对存有业务相关数据和客户敏感数据的数据库系统，需要对数据库进行必须的帐号管理、授权管理、密钥管理、数据访问控制等，确保对客户数据进行分离度隔离，避免造成数据污染。
参照：第6、7章节

5.4 网络安全及高可用

需要确保提供业务的网络环境具备必要的安全能力，包括但不限于网络防火墙、访问控制管理、路由管理、网络异常行为检测、防DDOS &CC攻击等。
参照：第6、7章节

5.5 业务应用软件安全

业务应用软件安全不仅包括提供服务的运行环境的安全，如使用容器的安全，还包括业务软件自身的漏洞、业务相关使用风险、流程设计缺陷、开放接口的安全能力等。
参照：第6、7章节

5.6 数据采集合规

业务采集的所有数据都需要在饿了么平台进过鉴权，完成授权以后才可以进行采集，严禁未经许可擅自收集或者引导客户录入不合规数据。
参照：第8章节

5.7 数据安全存储

业务运行期间产生的数据包括日志需要进行安全存储，如有需要，对数据进行加密保护，密钥需要安全保存，严禁将密钥在本地明文保存。
参照：第8章节

5.8 数据隔离

当业务同时向多个客户提供服务时，需要对数据进行相同粒度的隔离和使用，避免用户数据的非正常使用和泄露，确保不同客户彼此数据的完全隔离。
参照：第8章节

5.9 身份及授权管理

业务服务和管理人员需要提供有效的身份认证和授权管理机制，做到数据最小化访问和使用，要根据人员角色变化及时调整权限，避免出现敏感数据由于业务操作人员的不当访问和使用导致的泄露风险。
参照：第7章节

5.10 数据使用审批及审计

对业务人员的数据操作和使用需要有完善的审批和审计机制，要做到事前审批，事后审计，及时发现数据的不正当使用情况，并根据风险情况做必要的处置。
参照：第7章节-安全审计部分

5.11 数据安全共享

任何与第三方组织之间的数据共享都需要提前经饿了么平台授权许可，不得在未经许可的情况下将数据共享给第三方。获得许可后，需要采取有效的措施对数据的访问进行控制确保只有已授权用户才可以对共享数据进行操作。需要与第三方明确相关的数据安全风险，必要时需要和饿了么团队一起对数据进行预处理。
参照：第8章节

5.12 数据销毁管理

对授权失效的数据要做必要的安全销毁管理，根据数据的重要性和敏感程度采取不同手段对数据进行清除，如有必要对相关的存储设备和介质进行销毁或弃用。
参照：第8章节

5.13 运维风险安全管理

业务运营人员需要密切关注业务运营的各项风险指标，对异常信息要做到早发现、及时通报、即时处理。
对运维人员的数据访问权限做必要的访问控制，对敏感数据或大量数据的操作需要做审批和备案管理。
参照：第10章节

5.14 服务人员安全培训

对部署服务人员进行安全培训，明确服务标准，提高服务人员数据安全意识，对于服务过程中接触到的客户数据需要严格保密。
参照：第10章节

5.15 服务人员安全管理

对部署服务人员的日常工作和行为进行管理，不得私自获取客户数据，对违规行为要采取必要处罚措施，有效管理服务人员的流动，避免造成客户数据泄露。
参照：第10章节

6.零售云安全技术配置

本部分是对开发者应用所依赖云设施的技术配置所提出的安全要求，包括：内置的云安全功能的启用、应用所依赖的主机资源（如：ECS主机和RDS等）的安全性配置和应用相关访问时的安全性配置。

6.1 边界防护

安全项	具体要求
应用主机ECS要求	a）每台ECS主机只能被指定到唯一的安全组且该ECS主机所属的安全组不能更改； b）对于在同一个安全组内的ECS主机其网络是可互通的，但对该安全组外的ECS主机其网络是不可互通的。
应用安全隔离	如果同一个开发者有多个应用，开发者应为不同的应用使用不同的APP Key，不同的应用需要独立部署在零售云内不同的ECS主机中，确保应用之间是被安全隔离的。
ECS主机入驻御城河	系统管理员应在零售云管理后台中的御城河管理页中开启并设置御城河安全边界，将ECS主机划分到不同的安全边界里，边界间网络隔离（避免因一台ECS主机被入侵所有资源面临高风险的问题）。

6.2 攻击检测及防御

安全项	具体要求
主机入侵检测服务	开启御城河-主机入侵检测服务，从而具备其常见的主机入侵风险检测能力。
开启云盾功能	安全管理员应进入云盾控制台，开启云盾具备以下功能： a）ECS主机系统具备内外双向网络流量监控的能力； b）ECS主机系统能抵抗内外部网络发起的拒绝服务攻击； c）ECS主机系统具备脆弱性检测的能力，检测Web漏洞，检测弱口令的能力。
安装云盾客户端	ECS主机系统应安装云盾客户端（安骑士），从而具备以下安全功能： a）ECS主机系统具备对网站后门Web shell的查杀能力； b）ECS主机系统具备异地登录告警的功能； c）ECS主机系统具备口令暴力破解拦截能力； d）ECS主机系统具备异常系统账号检测并告警的能力。
开启WAF	安全管理员应进入云盾控制台，开启WAF功能，从而使应用具备以下安全功能： a）具备SQL注入攻击防御能力； b）具备Web shell上传拦截的能力； c）具备对扫描行为进行及时发现并告警和阻断的能力； d）具备针对Web用户的IP设置为白名单的能力； e）具备代码执行攻击防护能力 。

6.3 主机安全配置

安全项	具体要求
ECS主机管理员账号的重命名及默认口令的修改	系统管理员应在安装完成后，对ECS主机系统管理员的默认账号进行重命名，并修改账号的默认口令，修改后的口令应达到一定的口令强度。说明： a) 对于Windows，应重命名Administrator； b) 对于Linux，应为需要相关权限的账号配置sudo权限，并且限制root登录。 c) 密码规则：长度为8~32个字符。由大写字母、小写字母、数字、特殊字符中的任意三种组成。特殊字符为!@#$%^&*()_+-=
RDS管理员账号的重命名及默认口令的修改	数据库管理员在完成RDS数据库的初始化后，对RDS管理员的默认账号进行重命名，并修改账号的默认口令，修改后的口令应达到一定的口令强度。说明: a) 对于mysql类型的RDS数据库，应重命名管理员账号 root；禁止root远程登录； b) 对于sql server类型的RDS数据库，应重命名管理员账号 sa；禁止sa远程登录； c) 密码规则：长度为8~32个字符。由大写字母、小写字母、数字、特殊字符中的任意三种组成。特殊字符为!@#$%^&*()_+-=
删除ECS主机无用账号	系统管理员应在安装完成后，删除ECS主机的临时账号和测试账号。
删除RDS无用账号	数据库管理员应在安装完成后，删除RDS的临时账号和测试账号。
匿名登录	对于部署在ECS主机系统上的FTP应用程序，应不得开启匿名登录的功能，其FTP目录不得为操作系统的根目录，并同时不能在Web的目录下。
访问端口	a) ECS主机对公网的默认开放端口仅包括：80、443； b) 相关数据库的服务端口不能直接对公网进行开放； c) 对于在同一个安全组内的ECS主机之间，其端口都是直接开放且可相互访问的，但在不同的安全组之间的ECS主机之间，其端口默认是禁止的且网络是隔离的。
管理端口	系统管理员应在御城河管理后台中进行安全边界的设置，使ECS主机系统限定来自外界对边界内的ECS主机访问，只开放少数且必须的服务端口（如登录端口22/3389、web服务端口80/443，后台管理端口8080）。

7. 零售云应用安全配置

7.1 访问控制

基于白名单：应用应检查并绑定访问者的昵称白名单和访问来源的IP白名单，并提供绑定白名单的列表。
a）对于APP IP白名单，应用管理员应在零售云控制台中设置应用调用API的IP访问来源范围，应绑定主机外网IP且不允许绑定IP网段；
b）对于RDS IP白名单，应用管理员应在零售云控制台，为每一个RDS支持可以访问的ECS主机 IP范围，只允许其配置为特定的1个或多个IP且不允许绑定IP网段，默认情况下RDS是没有外网的访问权限的。
基于黑名单：应用应提供黑名单的保护机制，通过黑名单来拦截非法的访问，黑名单的纬度包括IP、用户账号和终端标识。

7.2 后台管理

本部分是对应用的后台管理所提出的安全要求，包括对后台管理所使用的终端的安全要求、后台管理的安全要求。

安全项	具体要求
限制登录	应用管理员应在零售云管理后台的御城河管理页面中，为ECS主机“添加VPN服务器”，来限制用户对应用和管理后台的登录，通过VPN拨入或者通过特定的IP登录。
登录管理后台	应用管理员若登录安全边界内的ECS主机以及访问8080端口的管理后台，应通过千牛PC客户端的“ECS主机远程登录”功能和“应用后台”插件、或者通过御城河VPN来实现。
终端屏幕保护	应用的后台管理的终端应设置屏幕保护程序及口令保护功能。说明：后台终端的操作系统应配置锁屏保护功能，当后台管理用户操作空闲超过一定时间(如10分钟)应锁定屏幕,用户重新激活必须再次认证，防止非授权用户的非法操作（如在用户离开期间）。
禁用终端的	应用的后台管理终端应禁用Guest账户。
重命名终端的默认账号	应用管理员应对应用管理员的默认账号进行重命名，并修改账号的默认口令，修改后的口令应达到一定的口令强度。
终端的补丁管理	a）应用的后台管理终端应制定相应的操作系统和必要应用程序的补丁管理计划，定期或不定期的维护； b）对于高危漏洞应在24小时内完成修复，对于其他级别的漏洞应在七天内完成修复。
禁用终端的其他应用程序	应用的后台管理终端应仅限于执行后台管理的业务功能，终端上不得安装与该业务功能无关的应用程序，和来源不明的应用程序。
终端的病毒防护	应用的后台管理终端应安装防病毒软件，防护范围包括但不限于病毒、特洛伊木马、蠕虫病毒、间谍软件、广告软件和rootkit内核型病毒等恶意代码。
终端的病毒库更新	应用管理员应定期进行病毒库更新及全盘杀毒，防病毒软件应设置有系统全盘扫描计划（如每周执行一次），开启病毒库的自动更新。
管理员指南	对于应用的后台管理员，开发者应提供详尽全面的操作指导文档（如电子文档或纸质文档），就管理员如何以安全方式使用终端进行详细而全面的说明，便于管理员查询，覆盖内容应包括：屏幕保护、禁用访客账号、重命名默认账号、系统补丁、禁用其他应用程序、病毒防护、病毒库更新等。
风险提示	开发者在文档中对于影响后台管理安全性的操作（如修改口令、更换密钥），应明确提示相关的风险。对于会影响应用正常运行的关键配置项和操作，文档中也应用警告标志标示，并明示其可能的影响。

7.3 应用安全功能开发

本部分是对开发者应用应开发实现的安全功能所提出的安全要求，包括：账号管理、身份认证、权限管理和安全审计。

账号管理、身份认证、权限管理：

安全项	具体要求
账号唯一	应用应为不同的用户分配不同的账号，确保一个用户一个账号，应禁止多人使用同一个账号。
账号风控	应用应接入阿里巴巴的御城河账号风控，使其具备保护和管理平台账号的安全能力，能及时地识别账号的异常风险（包括但不限于账号被盗、暴力破解等问题），并给予及时的管控。
账号锁定	应用应通过在达到六次登录尝试后锁定用户账号的方式限制反复访问尝试；锁定持续至少30 分钟，或者直到管理员启用该用户账号。
账号有效期	应用应对用户账号和应用管理员的账号设置有效期。
无用账号删除	应用应及时删除或禁止多余的、过期的用户账号，避免共享账号的存在。
账号权限回收	应用应及时清理和回收应用相关的开发账号、测试账号和后台管理账号及权限，如：相关账号使用者离职或转岗时。
初始口令	应用管理员账号的初始口令应为系统随机产生的满足口令强度要求的口令。
口令更换	应用应定期（每半年）提醒用户对口令进行修改，建议口令至少每六个月更换一次。
口令强度	口令强度应同时满足如下要求： a) 应用应保存加密后的口令历史，并要求新口令与前四次使用的口令不同； b) 口令不能为空； c) 不允许使用默认口令； d) 口令长度至少8位以上； e) 包含字母大写、字母小写、数字、特殊字符其中的三种或以上，不能使用连续字母或单纯数字，不能使用键盘上连续字符； f) 不能使用与用户自身强关联（如生日、姓名）的单词。
口令重置	应用应提供给用户口令重置功能，口令重置的功能需要经过开发者客服人工确认或者经过“组合鉴别”通过才能生效，且重置后的口令必须通过短信、邮件等用户绑定的可信任的渠道告知用户。
重新验证	当会话空闲超过30分钟，应用应要求用户重新验证或重新激活会话。
登录控制	应用应对登录应用的用户进行身份标识和鉴别。
组合鉴别	a) 应用应支持对同一用户采用两种或两种以上组合的鉴别技术（口令验证、邮箱验证、短信验证等）实现用户身份鉴别； b) 在执行敏感操作（口令修改或重置）或账号行为异常的情况下，应用应采用两种或两种以上的组合鉴别方式。 说明：短信、邮箱验证可以通过发送验证信息到用户绑定的可信手机号或邮箱中，并且需要对验证信息设置过期时间，建议10分钟。

安全审计：

安全项	具体要求
审计所有用户的行为和操作	应用应提供覆盖到每个用户的安全审计功能，对应用重要安全事件进行审计；审计内容应包括重要用户行为（包括：所有的登录访问、RDS的调用、OpenApi的调用、来自用户端的访问和订单的传递等）以及系统资源的异常使用和重要系统命令的使用等系统内重要的安全相关事件。
日志存储保护	应用应保护所存储的日志审计记录的完整性，避免其受到未预期的删除、修改或覆盖等。
日志保存期限	应用应保存日志至少六个月。
用户端的应用日志	应用应通过接入御城河-孔明锁（在页面上部署阿里巴巴提供的Java script代码，或者在客户端中引入阿里巴巴的SDK），记录和上报来自用户端的日志。
服务器端登录日志	a) 应用应通过调用阿里巴巴提供的御城河日志API，记录和上报应用所有的登录日志，包括且不限于：1）用户登录应用的日志； 2）应用管理员登录管理后台的登录日志；3）主机端进行的系统登录。 b) 日志的内容应包括：时间、用户在开发者的自有账号、用户的饿了么账号、应用标识（App Key）、应用名称、源IP和登录结果（成功或失败）等
服务器端订单访问日志	a) 应用应通过调用阿里巴巴提供的御城河日志API，记录和上报用户通过应用查看、管理、导出订单的详细日志。 b) 日志的内容应包括：用户在开发者的自有账号、源IP、时间、应用标（App Key）、应用名称、订单URL、订单号列表和对订单的操作等
服务器端向第三方应用传递订单日志	a) 应用应通过调用阿里巴巴提供的御城河日志API，记录和上报应用服务器之间的涉及到订单的所有数据通信记录，包括且不限于：1）同应用内部的订单接口访问；2）不同应用之间的数据传递，如OMS到WMS。 b) 日志的内容应包括：源IP、时间、用户在开发者的自有账号、应用标识（App Key）、应用名称、请求的URL、订单号列表和订单推送的目的地URL等。
服务器端调用RDS日志	a) 应用应通过调用阿里巴巴提供的御城河日志API，记录和上报服务器端调用RDS的日志； b) 日志的内容应包含：用户在开发者的自有账号、源IP、时间、应用标识（App Key）、用户请求的URL、连接RDS的实例域名和SQL语句等。
服务器端调用OpenApi日志	a) 应用应通过调用阿里巴巴提供的御城河日志API，记录和上报服务器端调用OpenApi的日志； b) 日志的内容应包括：源IP、时间、用户在开发者的自有账号、应用标识（App Key）、应用名称和用户调用TOP API的URL等。
通用隐私数据访问日志	a) 应用应通过调用阿里巴巴提供的御城河日志API，记录和上报用户通过应用查看、管理、导出通用隐私数据的详细日志； b) 日志的内容应包括：用户在开发者的自有账号、源IP、时间、应用标识（App Key）、应用名称、订单URL和对订单的操作等； c) 隐私数据包括不限于用户手机号、用户收货地址和用户敏感属性等。

7.4 安全编码

ISV、企业开发应用套件、需参考并遵循饿了么官方提供的安全开发规范。
《Java安全开发规范》
链接：https://yq.aliyun.com/download/2719

8. 零售云数据安全

8.1 数据产生

按照数据类型、敏感程度、数据价值等相关属性明确数据分类分级标准。在数据产生时，统一对数据进行分类分级打标，确保业务流转过程中，所有数据按照策略规范要求实施分类管控，分级授权。

8.2 数据获取

禁止应用从零售云外部的服务器上发起OpenApi的数据请求，这些应用的标签包含但不仅限于ERP/进销存软件、开发者后台系统、商家后台系统、客户关系管理、促销管理、订单管理、订单付费、商品管理、仓储管理系统、在线订购应用、协同办公、快递运输应用、电商财务、全渠道ERP、行业/店铺分析、客户服务等。

8.3 数据传输

安全项	具体要求
传输加密	a) 应用中涉及敏感数据（比如订单数据等）的传输必须进行加密传输，实现系统管理数据、鉴别信息和重要业务数据的传输保密性； b) 加密算法应使用AES-128位或以上强度。
应用间的数据交互	聚石塔内部的应用涉及敏感数据（比如订单数据等）与其它应用（包括同一个开发者的不同应用和不同开发者的应用）的数据传输（包括聚石塔内部应用之间的数据传输、聚石塔内部应用与外部应用之间的数据传输），应通过奇门所定义的标准化协议进行数据传输。
对外数据传输-奇门	聚石塔内部的应用涉及敏感数据与其它应用的数据传输，应通过奇门所定义的标准化协议或奇门自定义协议进行数据传输。参考：https://open.taobao.com/doc.htm?spm=a219a.7386797.0.0.f3d3669aFPZae5&source=search&docId=106847&docType=1

8.4 数据使用

安全项	具体要求
数据处理	应用在对其敏感数据（比如订单数据等）进行后台的处理或计算时，其相关功能的组件和模块应部署在聚石塔内部的系统里。
数据展示	在前端应用层面，涉及页面全部数字水印处理，敏感信息需经过加密或脱敏处理。建议的脱敏方案： a) 【手机号】显示*+后 4 位。如：******1050； b) 【固定号码】显示区号和后三位，如0571-*123；c) 【邮箱】例如tt@163.com则显示为tt@1.com； d) 【收货地址】隐藏区/县级以下部分的地址。在服务端层面，必须统一接入权限管理系统，访问主体必须根据权限、角色和风险级别按需申请，并详细说明访问内容、访问理由、访问时长等相关信息，获得的访问权限定期复核，离职转岗后权限关闭。在数据库操作层面，增删改查的操作命令全程监控，操作日志集中存储，操作流量实时分析，一旦发现高危sql语句、批量违规操作、危险时段异常操作等违背安全管理要求等行为，及时告警并可实时在线拦截。

8.5 数据存储

安全项	具体要求
口令存储	应用对用户口令应使用安全的不可逆的加密算法进行加密保存，防止特权用户获取用户口令。
Access Token存储	a) 应用对其获取访问用户数据的Access Token（授权令牌，即原来的Session Key），应按照平台认可的安全方案进行加密存储； b) 如该Access Token涉及访问用户的隐私数据，该Access Token（授权令牌，即原来的Session Key）应存储在聚石塔内。
订单储存	应用中的数据应存储在聚石塔内，涉及饿了么订单数据，应使用RDS进行数据存储，并且绑定内网IP白名单。
隐私储存	应用存储的消费者隐私数据，应按照平台认可的安全方案进行加密存储。
备份恢复	应用应开启ECS主机和RDS的云快照和备份的功能，定时对云服务进行备份。

8.6 数据共享

在对外数据开放共享方面，饿了么严格遵循《网络安全法》要求，以用户隐私信息保护为首要前提，制定对外数据披露细则，明确要求所有对外数据输出必须遵循以下原则：

安全项	具体要求
保护用户隐私	涉及用户隐私数据未经客户的充分授权，不得收集、分析或向任何第三方输出。
必要性和最小化	对外数据输出时必须将数据的范围、数量及知情者控制在最小范围内，因法律法规要求需向公众公平公开输出数据的情况除外。
合规性	对外数据合作必须遵循适用于阿里巴巴集团的规范、协议、政策、行业标准等要求。

8.7 数据销毁

对授权失效的数据要做必要的安全销毁管理，根据数据的重要性和敏感程度采取不同手段对数据进行清除，如有必要对相关的存储设备和介质进行销毁或弃用。
带有敏感数据的纸质材料，如不再使用，及时进行销毁；数据所属部门或数据管理部门定期开展数据可用性评估，不再使用或较长时间不使用的数据，及时予以销毁。
数据介质出数据中心前遵照 DoD 5220.22-M、 NIST 800-88 标准进行清除数据、磁盘消磁以及物理销毁，避免数据泄露风险。
企业通过开放平台注册提交的信息，禁止进行数据销毁，避免出现处理业务事件、安全事件，无法查看企业信息。

9. 零售云用户使用的安全风险告知

本部分是对开发者应用在被使用的过程中，用户应知晓和注意的相关安全风险所提出的安全要求，包括：通过用户手册和系统提示的途径告知用户如何有效地使用应用的安全功能，以及用户应注意和避免的不良使用行为。

9.1 用户手册

安全项	具体要求
安全功能介绍	对于应用的商家用户，开发者应提供详尽全面的操作指导文档（如帮助文件和纸质文档），便于用户查询，用于指导用户使用或配置开发者提供的应用的安全功能。在文档中应写明应用中所提供的安全功能介绍，对于用户影响系统安全性的操作（如修改口令、配置权限等），在操作时应明确提示相关的风险；对于会影响应用正常运行的关键配置项和操作，文档中也应用警告标志标示，并明示其可能的影响。
应用间的数据交互	a) 开发者应告知用户对口令进行安全保护，包括：检验口令强度并提示用户设置强口令、设定口令修改默认时期，到期提示修改口令、口令不得存储在本地； b) 开发者应告知用户终端的安全使用需要注意的不安全的日常使用行为和基本安全建议：包括：屏保的安全设置、操作系统的及时升级、防病毒软件的有效安装、主机防火墙的正确配置、应用软件的下载与安装； c) 开发者应告知用户移动终端的安全使用，包括：设置屏幕解锁口令或图案、防病毒软件的有效安装等； d) 开发者应告知用户移动介质的安全管理，包括：U盾、U盘、移动硬盘的安全存放，设置用户口令等； e) 开发者应告知用户互联网的安全访问的注意事项，包括：无线上网、浏览上网、电子邮件、社交网络、即时通信、网上交易等方面； f) 开发者应告知用户防止基于社会工程的欺诈，包括：基于人：物理的非授权访问；基于电话：呼叫者电话的欺骗；基于电子邮件：钓鱼攻击、Email地址欺骗；基于即时通信软件：通过QQ、微信等的欺骗

9.2 系统提示

安全项	具体要求
使用风险提示	应用应在合适的界面提示用户使用应用时的安全风险及学习安全指南的建议，至少应包括：不开启云盾的风险、口令被盗的风险、使用默认账号的风险、使用共享账号的风险。
终端风险提示	应用应在合适的界面提示用户终端安全方面的风险及学习安全指南的建议，至少应包括：病毒感染的风险、不及时安装补丁的风险、使用访客账号的风险、使用默认账号的风险、不进行口令保护的风险、不设置屏幕保护的风险。

10. 管理保障

10.1 开放平台管理

10.1.1 系统架构设计文档
ISV应针对应用的不同版本，应交付规范的应用设计文档给饿了么开放平台，内容包含：范围、目标、设计约束、威胁分析、设计需求、设计原则、系统架构图、系统流程及功能模块。

10.1.2 安全功能规格文档
ISV应提交给饿了么开放平台全面详尽的安全功能设计规格文档，阐明系统各个安全功能的基本实现原理及相关设计规格，内容涵盖威胁分析、安全需求、设计原理、及支持的规格（如密钥的算法、密钥长度，通信加密协议及密码算法、口令强度）；
所述安全功能包括但不限于所列的安全功能需求。

10.1.3 版本修订
ISV的应用开发过程中应包含安全活动的实施，如安全需求分析（威胁分析）、安全设计（安全架构及安全功能设计）、安全开发（安全编码、静态代码扫描、及人工代码检视）、安全测试（安全功能测试及渗透测试）；
对于小型的版本修订（即功能改进），ISV应提供详尽的版本修订说明（含修订的安全影响分析）；对于大规模的版本修订，应用服务应提前通报饿了么平台以启动重新的安全评测。

10.2 漏洞管理

安全项	具体要求
漏洞扫描	在应用上线运行前，开发者应对前后台系统执行漏洞扫描，保证上线应用不存在漏洞，并将扫描结果提交给饿了么。
漏洞修复	开发者应对漏洞进行跟踪管理，要求高危漏洞24小时内修复，中危漏洞3天修复，低危漏洞7天修复。
渗透测试	开发者应提供给饿了么渗透测试报告，所评测应用应通过饿了么开放平台上线审核安全测试/渗透测试。上线应用不可存在如下漏洞：命令执行漏洞、用户信息泄露、代码执行漏洞、上传漏洞、SQL注入、权限漏洞、跨站脚本漏洞、CSRF漏洞、URL跳转漏洞。该测试需由饿了么或饿了么授权的独立第三方独立进行。针对BS架构及有WEB服务的CS架构，饿了么安全工程师可以帮助进行针对系统的渗透测试。
漏洞信息通报	a) 开发者发现饿了么平台存在缺陷时，应及时向饿了么通报。任何情况下，均不应隐瞒或恶意利用； b) 开发者发现自研应用、操作系统及所用到的相关第三方应用程序/代码组件中存在安全漏洞时，应及时向饿了么通报。任何情况下，均不应在生产环境下尝试验证弱点。

10.3 运维保障

安全项	具体要求
安全职责明确	开发者应将相关人员（开发、测试、运维、管理等）的安全职责向饿了么进行报备。
安全专职负责人	开发者应指定专职的安全负责人作为与饿了么安全团队的安全接口人，并且在御城河平台上设置安全负责人，定期保持安全联络和沟通。
安全意识教育	开发者应对相关人员（开发、测试、运维、管理等）每年进行至少一次的安全意识教育，并对安全教育和培训的情况和结果进行记录并归档保存。
安全制度学习	开发者应建立和文档化其必要的安全制度和操作流程，并要求相关人员（开发、测试、运维、管理等）每年至少一次确认自己已经阅读并了解公司的安全要求和制度流程。
安全责任书	开发者的相关人员（开发、测试、运维、管理等）应签订数据安全责任书。
安全自查	开发者应至少每年执行一次安全自查，并在环境发生重大变更时（例如收购、合并、迁址等）不定期地对线上应用执行安全评估，根据安全评估执行相应操作（如补丁管理、软件升级、系统加固等），并将该安全评估结果和安全整改情况通报给饿了么相关的接口人。
风险处置	a) 开发者应及时、有效地配合饿了么日常的服务排查，不应做出屏蔽饿了么IP等恶意行为； b) 由御城河产出的各类安全风险，应在其规定的时间内完成处置，包括：高危风险的处置应在24小时内完成，中危风险的处置应在3天内完成，低危风险的处置应在7内完成。
服务和端口开放	应用（含前后台）应附有详细的列表，列明应用所必须使用的系统服务和通信端口，且应仅开放应用运行所必须的系统服务和通信端口。
变更管理	a) 开发者应识别应用开发和运维中的主要变更需求，并制定相关的变更方案； b) 开发者应建立相关的变更流程和审批机制； c) 当相关系统变更时，开发者应向所有相关人员（开发、测试、运维、管理等）通告；实施变更时，必须进行记录且应妥善保存这些记录。
应急响应	a) 开发者应制定安全事件报告和处置管理制度，明确安全事件的现场处理、事件报告和后期恢复的角色职能及处理流程； b) 开发者应建立负责线上应急响应的团队，明确安全事件响应的角色和责任人员/组织； c) 开发者应制定有7X24应急响应计划（突发安全事件预案），并定期演练； d) 开发者应监控相关软件程序的安全漏洞和威胁情报，及时修复应用及相关支撑系统的安全漏洞； e) 开发者应记录和保存所有报告中的安全弱点和可疑事件，分析事件原因，监督事态发展，并采取措施避免安全事件发生。