开放接口/RESTful/Api服务的设计和安全方案

总体思路 这个涉及到两个方面问题: 一个是接口访问认证问题,主要解决谁可以使用接口(用户登录验证、来路验证) 一个是数据数据传输安全,主要解决接口数据被监听(HTTPS安全传输、敏感内容加密、数字签名) 用户身份验证:Token与Session 开放接口Api服务其实就是客户端与服务端无状态交互的一种形式,这有点类似REST(Representational State Transfer)风格。 普通网站应用一般使用session进行登录用户信息的存储和验证(有状态),而开放接口服务/REST资源请求则使用Token进行登录用户信息的验证(无状态)。Token更像是一个精简版的session。Session主要用于保持会话信息,会在客户端保存一份cookie来保持用户会话有效性,而Token则只用于登录用户的身份鉴权。所以在移动端使用Token会比使用Session更加简易并且有更高的安全性,同时也更加符合RESTful中无状态的定义。 Token交互流程 客户端通过登录请求提交用户名和密码,服务端验证通过后生成一个Token与该用户进行关联,并将Token返回给客户端。 客户端在接下来的请求中都会携带Token,服务端通过解析Token检查登录状态。 当用户退出登录、其他终端登录同一账号、长时间未进行操作时Token会失效,这时用户需要重新登录。 Token生成原理 服务端生成的Token一般为随机的非重复字符串,根据应用对安全性的不同要求,会将其添加时间戳(通过时间判断Token是否被盗用)或url签名(通过请求地址判断Token是否被盗用)后加密进行传输。一般Token内容包含有:用户名/appid,密码/appsecret, 授权url,用户自定义token(用户自定义签名),时间戳,有效期时长(秒), 系统签名(sign)等。 Api接口服务调用流程: 1. 首先要获取全局唯一的接口调用凭据(access_token)。该过程务必使用https安全传输协议,否则被拦截监听了,用户名和密码等重要数据就都泄漏了。 具体过程: a. 客户端向服务端通过https协议发送请求,参数包含用户名、密码、请求类型等 b. 服务端接到请求后,验证用户信息是否正确,如果正确,返回access_token和expires。否则返回errorcode和errmsg。 c. 服务端access_token可以存储在session或者redis等内存数据库中,键名(key)为user_id,键值为access_token。 d. 客户端获得access_token后,保存到file或redis等内存数据库中。不推荐保存到session或数据库中,保存到session数据容易丢失,保存到数据库因为涉及IO读写,性能较低。 2.…

Continue Reading 开放接口/RESTful/Api服务的设计和安全方案

关于 RESTFUL API 安全认证方式的一些总结

常用认证方式 在之前的文章REST API 安全设计指南与使用 AngularJS & NodeJS 实现基于 token 的认证应用两篇文章中,[译]web权限验证方法说明中也详细介绍,一般基于REST API 安全设计常用方式有: HTTP Basic Basic admin:admin Basic YWRtaW46YWRtaW4= Authorization: Basic YWRtaW46YWRtaW4= 由于HTTP协议是无状态的,所有每次请求都得带上身份信息,基于Http basic验证就是简单的将用户名和密码base64编码放到header中,一般需要HTTPS,安全性较低,实现的方式可以基于代码实现也可以基于web容器配置apache,nginx等web服务器即可实现。 HTTP Digest 摘要认证 digest authentication,服务器端以nonce进行质询,客户端以用户名,密码,nonce,HTTP方法,请求的URI等信息为基础产生的response信息进行认证的方式。 ※ 不包含密码的明文传递…

Continue Reading 关于 RESTFUL API 安全认证方式的一些总结

REST API 安全设计指南

http://blog.nsfocus.net/rest-api-design-safety/   REST API 安全设计指南。REST的全称是REpresentational State Transfer,它利用传统Web特点,提出提出一个既适于客户端应用又适于服务端的应用的、统一架构,极大程度上统一及简化了网站架构设计。 目前在三种主流的Web服务实现方案中,REST模式服务相比复杂的SOAP和XML-RPC对比来讲,更加简洁,越来越多的web服务开始使用REST设计并实现。但其缺少安全特性,《REST API 安全设计指南》就是一个REST API安全设计的指南,权当抛砖引玉,推荐网站后台设计及网站架构师们阅读。 文章目录 1,REST API 简介 2,身份认证 2.1 HTTP Basic 2.2 API KEY 2.3 Oauth1.0a或者Oauth2 2.4 JWT 3 授权 4 URL过滤…

Continue Reading REST API 安全设计指南

面向业务的智能运维:中国移动智能运维系统探索与实践

作者:胡建华 中国移动苏州研发中心,IT支撑产品部,技术研究员 主要从事集中化系统架构设计,以及数据保护(存储、备份、云盘)、智能运维相关领域的技术研究和开发工作。 1、BAIOPS-业务智能运维 智能运维(AIOps-Algorithmic IT Operations基于算法的IT运维)是人工智能技术在IT运维领域的运用,引用Gartner 的报告的一段话“到2020年,将近50%的企业将会在他们的业务和IT运维方面采用AIOps,远远高于今天的10%”,最近2-3年智能运维的概念随处可见,各大互联网公司、传统IT公司、金融业等都在谈他们的智能运维设想,同时也有人谈AI色变,觉得人工智能只是一个愿景,要落地很难。其实AI已经不是一个新的概念了,百度、微软、谷歌等公司早就在10几年前开始自己的人工智能布局了,到现在均已成为人工智能行业的领跑者了。 话不多说,人工智能那么强大,应用场景十分的广泛,当然也包括运维领域,而且面向业务的运维更是运维发展的热点趋势,下面我就和大家就“面向业务的智能运维体系建设的探索与实践”这个话题发表下我的个人见解。   2、传统运维-痛之又痛   传统的运维中,存在着诸多痛点: (1)被动低效的运维难以保证业务连续性 运维人员往往扮演着事后“救火”的角色,待事故发生后才去处理; 数据分散在多处,出了故障无法快速修复,业务连续性难以有效保障; 随着业务复杂性不断提高,人工运维的成本呈指数级增长。 (2)缺乏统一的运维监控体系和技术工具 针对不同运维实体的烟囱式的运维工具,功能重叠、难以整合; 运维的自动化程度偏低,运维脚本泛滥,层次化、模块化程度不足; 监控、运维、告警平台林立,各成体系,缺乏统一化体系。 (3)海量的运维数据的价值无法充分挖掘 传统运维系统收集了大量的运维数据,但是却缺乏有效的手段加以分析和利用; 运维数据的利用仅限于简单的可视化和浅度的分析上,缺乏纵向数据的关联挖掘,无法快速定位故障根因; 固定式的阈值告警造成了大量的误判和漏判,而且人工调整阈值的方式也比较费时费力。 (4)缺乏全方位端到端的运维监控手段 大部分的运维监控仅停留在针对主机、网络的层面,忽略了业务层面的识别手段,故障的发生无法从最直接的业务层面得以发现,产生预警; 性能管理大多停留在服务单应用性能的管理和分析上,无法提供端到端的掌控。   3、业务智能运维的切入点…

Continue Reading 面向业务的智能运维:中国移动智能运维系统探索与实践

手把手教你构建一个高性能、高可用的大型分布式网站

本文是学习大型分布式网站架构的技术总结,对构建一个高性能、高可用、可伸缩及可扩展的分布式网站进行了概要性描述,并给出一个架构参考。 文中一部分为读书笔记,一部分是个人经验总结,对大型分布式网站架构有较好的参考价值。 大型分布式网站架构技术 大型网站的特点 大型网站一般有如下特点: 用户多,分布广泛 大流量,高并发 海量数据,服务高可用 安全环境恶劣,易受网络攻击 功能多,变更快,频繁发布 从小到大,渐进发展 以用户为中心 免费服务,付费体验 大型网站架构目标 大型网站的架构目标有如下几个: 高性能:提供快速的访问体验。 高可用:网站服务一直可以正常访问。 可伸缩:通过硬件增加/减少,提高/降低处理能力。 扩展性:方便地通过新增/移除方式,增加/减少新的功能/模块。 安全性:提供网站安全访问和数据加密、安全存储等策略。 敏捷性:随需应变,快速响应。 大型网站架构模式 如上图是大型网站的架构模式: 分层:一般可分为应用层、服务层、数据层、管理层与分析层。 分割:一般按照业务/模块/功能特点进行划分,比如应用层分为首页、用户中心。 分布式:将应用分开部署(比如多台物理机),通过远程调用协同工作。 集群:一个应用/模块/功能部署多份(如:多台物理机),通过负载均衡共同提供对外访问。 缓存:将数据放在距离应用或用户最近的位置,加快访问速度。 异步:将同步的操作异步化。客户端发出请求,不等待服务端响应,等服务端处理完毕后,使用通知或轮询的方式告知请求方。一般指:请求——响应——通知模式。 冗余:增加副本,提高可用性、安全性与性能。…

Continue Reading 手把手教你构建一个高性能、高可用的大型分布式网站