新手指南

接入流程

接入流程

一、申请成为开发者

路径:首页-成为开发者

申请成为开发者
  • 1.开发者在首页页面中部区域点击成为申请成为开发者
  • 2.按照页面提示信息,填写后提交申请
  • 3.平台会在1~2个工作日内完成信息审核
  • 4.开发者需根据实际情况选择开发者类型,提交信息与实际情况不予通过
  • 5.自研开发者和第三方开发者区别:
    • (1)自研开发者:商家自有研发团队申请,平台会审核商家的资质信息
    • (2)第三方开发者:为商家提供软件支持服务的研发团队申请,每次创建项目时可自行选择新项目支持管理连锁门店

二、创建项目

路径:开发者后台-项目列表-创建项目

创建项目
  • 1.开发者资质审核通过后,可在开发者后台-项目列表,创建新项目
  • 2.在项目内可以申请测试账号(source),用于开发测试
  • 3.平台对重要接口设置验收机制,此类接口需验收通过后才能在线上环境调用

三、开发测试

路径:开发者后台-项目列表-项目查看-项目详情

开发测试
  • 1.在项目详情添加测试合作方账号(source),添加成功后页面内新增展示测试合作方账号(source)信息
  • 2.添加合作方账号(source)时的下行接口地址是用于接收平台推送消息的服务地址
  • 3.测试合作方账号(source)创建成功后,平台会为此合作方账号(source)自动创建一个测试门店(商户列表可查看),账号密码和门店信息会通过邮箱下发
  • 4.开发者可使用合作方账号(source)和密钥进行接口测试

四、接口验收

路径:开发者后台-项目列表-项目验收

接口验收
  • 1.创建项目时勾选的需验收接口,必须验收通过后才能申请正式合作方账号(source)进入后续流程
  • 2.接口验收方法:调用需验收接口,调用成功后(调用后接口返回成功),在验收页面选择对应的合作方账号,点击去验收
  • 3.开发者接口验收列表可在“开发者后台-项目列表-项目查看-接口配置”中进行配置

五、商户授权

路径:开发者后台-项目列表-项目查看-门店绑定

商户授权
  • 1.开发者申请正式合作方账号(source)通过后,方可在门店绑定页面进行门店授权,测试合作方账号(source)和测试门店都无法进行门店授权,请不要将测试门店解除API授权
  • 2.每个正式合作方账号(source)对应一个绑定链接,打开绑定链接使用合作方账号(source)对应的供应商or门店的饿百商家端账号密码登录,勾选门店授权
  • 3.同一正式门店只能授权给一个合作方账号(source)
  • 4.门店关联合作方门店ID在“门店绑定-第三方门店ID映射”页面进行操作,或在商户列表点击对应门店的合作方商户ID进行操作,或可通过门店映射接口操作
  • 5.合作方商户ID在同一个合作方账号(source)内不能重复,关联后开发者可使用自有系统商户ID管理门店
  • 6.门店取消API关联,需使用取消绑定链接操作,打开此链接使用需解绑门店的饿百商家端账号密码登录,勾选门店解绑

接入方案

商品模块

应用场景:商家通过自有系统完成商品创建和修改,维护库存和价格,提高商品信息更新效率

建议对接接口:

  • sku.create-商品上传
  • sku.update-商品修改
  • sku.category.list-获取分类列表
  • sku.brand.list-获取品牌列表
  • sku.shop.category.create-新增商品自定义分类
  • sku.shop.category.map-绑定商品与自定义分类
  • sku.stock.update.batch-批量修改商品库存
  • sku.price.update.batch-批量修改商品价格

注意事项:

  • 1.创建商品接口中分类指后台分类,即平台归类使用,对用户不可见分类,通过获取分类列表接口获取
  • 2.创建商品成功后,需绑定自定义分类方可在用户端展示
  • 3.二级自定义分类最大值为20,有二级自定义分类的一级自定义分类不能绑定商品
  • 4.创建商品时upc字段命中平台标库upc,商品名称等信息默认使用平台标库信息
  • 5.不支持通过API修改商品upc
  • 6.若门店沿用供应商前台分类并且将此套分类同步到所有门店,对应门店首次调用自定义分类接口会触发解锁逻辑,即首次调用自定义分类接口报错

订单模块

售前方案

应用场景:商家系统确认订单,查看订单详情

建议对接接口:

  • order.create-创建订单
  • order.confirm-确认订单
  • order.get-查看订单详情

注意事项:

  • 1.用户下单后,商家可处理的时间为5分钟,超时未接单订单将自动无效
  • 2.平台通过接口推送订单均为已支付订单
  • 3.双平台订单推送和操作均以order_id字段为准,饿了么订单在order.get接口中单独给出eleme_order_id
  • 4.非自配送订单由骑手回传订单完成状态,自配送订单在商家接单一段时间后自动完成(饿了么订单接单3小时后、饿了么星选订单接单4小时后自动完成)
售前方案

售中方案-用户取消订单

应用场景:商家系统处理用户取消订单申请

建议对接接口:

  • order.user.cancel-用户申请订单取消/退款
  • order.agreerefund-同意用户取消订单/退款
  • order.disagreerefund-拒绝用户取消订单/退款
  • order.cancellist-获取未处理取消单/退单

注意事项:

  • 1.发起流程节点:订单完成前,用户可发起订单取消申请
  • 2.商家需在用户申请取消15分钟内处理用户申请,超时未处理默认同意用户取消申请
  • 3.商家拒绝用户取消申请,用户可以发起客服仲裁,由客服联系商家和用户处理订单取消事宜
  • 4.其他用户直接取消订单场景(无需商家同意,系统默认同意用户取消申请)
  • (1)非自配送订单商家接单1分钟内骑手未取货,或自配送订单商家接单1分钟内,用户可直接取消订单
  • (2)非自配送订单,订单超过预计送达时间+10分钟(预计送达时间由平台计算,在用户提交订单时页面展示)骑手还未取货,用户可直接取消订单
  • (3)非自配送订单且非预订单,订单超过预计送达时间+30分钟(预计送达时间由平台计算,在用户提交订单时页面展示)骑手还未送达,用户可直接取消订单
  • 5.开启门店订单取消功能路径:开发者后台->项目列表->项目详情->修改账号(source)->开启全单取消/退单
售中方案

售中方案-商家取消/部分退

应用场景:商家拣货过程中发现部分商品缺货,将缺货商品或整单商品退款给用户

建议对接接口:

  • order.partrefund.push-部分退款订单信息推送
  • order.partrefund-商户发起部分退款申请
  • order.partrefund.get-查看部分退款订单详情
  • order.cancel-取消订单

注意事项:

  • 1.发起流程节点:
    • (1)非自配送商家:商家接单后,骑手取餐前商家可发起部分退款或取消订单
    • (2)自配送商家:商家接单后至订单完成前,商家可发起部分退款或取消订单
  • 2.每笔订单订单完成前后各支持一次部分退款
  • 3.饿了么订单商家发起部分退款,系统默认用户同意(暂不支持饿了么星选订单部分退款)
  • 4.开启门店部分退款功能路径:开发者后台->项目列表->项目详情->修改账号(source)->开启部分退款

售后方案

应用场景:订单完成后,处理用户的全单/部分退款申请

建议对接接口:

  • order.user.cancel-用户申请订单取消/退款
  • order.partrefund.push-部分退款订单信息推送
  • order.agreerefund-同意用户取消订单/退款
  • order.disagreerefund-拒绝用户取消订单/退款
  • order.cancellist-获取未处理取消单/退单
  • order.partrefund.untrelist-获取未处理部分退订单
  • order.partrefund.get-查看部分退款订单详情

注意事项:

  • 1.发起流程节点:订单完成后,用户可发起全单退款或部分退款
  • 2.商家需在24小时内处理用户全单或部分退款申请,超时未处理默认同意用户全单或部分退款
  • 3.如果商家拒绝用户全单或部分退款申请,用户可以发起客服仲裁,由客服联系双方处理用户退款事宜
  • 4.开启门店全单退款功能路径:开发者后台->项目列表->项目详情->修改账号(source)->开启全单取消/退单
  • 5.开启门店部分退款功能路径:开发者后台->项目列表->项目详情->修改账号(source)->开启部分退款
售后方案

商户模块

应用场景:商家通过商家系统维护门店信息

建议对接接口:

  • shop.get-查看商户
  • shop.update-修改商户
  • shop.open-商户开业
  • shop.close-商户歇业
  • picture.upload-上传图片

注意事项:

  • 1.创建、修改商户的配送信息只对自配送生效,非自配送的配送范围需平台业务侧修改
  • 2.合作方门店ID在创建门店时可上传,存量门店可在“开发者后台-项目列表-项目查看-商户列表”或“开发者后台-项目列表-项目查看-门店绑定”进行修改
  • 3.图片参数需使用上传图片接口返回的url
商户模块

其他

【新零售商户端下载】

PC电脑客户端下载:点击下载

Android手机版下载:点击下载

ios手机版下载:直接应用商店搜索 饿百商家版

网页版直接登录:be.ele.me

开放平台应用安全实施指南 v1.0

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主机对公网的默认开放端口仅包括:80443

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)不同应用之间的数据传递,如OMSWMS

a)日志的内容应包括:源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 APIURL等。

通用隐私数据访问日志

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位或以上强度。
应用间的数据交互

a) 聚石塔内部的应用涉及敏感数据(比如订单数据等)与其它应用(包括同一个开发者的不同应用和不同开发者的应用)的数据传输(包括聚石塔内部应用之间的数据传输、聚石塔内部应用与外部应用之间的数据传输),应通过奇门所定义的标准化协议进行数据传输;

对外数据传输-奇门

聚石塔内部的应用涉及敏感数据与其它应用的数据传输,应通过奇门所定义的标准化协议或奇门自定义协议进行数据传输。

参考: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)开发者应记录和保存所有报告中的安全弱点和可疑事件,分析事件原因,监督事态发展,并采取措施避免安全事件发生;