什么是 API 安全
API 安全主要包括信息安全、网络安全、应用安全三个方面
信息安全
信息安全是你要保证系统所有的信息在它的整个的生命周期中，它应该是受到保护的，是安全的
所谓整个生命周期包括信息从创建开始、到存储、到转换、到备份、甚至到销毁
网络安全
- 信息通过网络传输的过程中是安全的，不会被人盗取或者篡改
- 你也应该保证在网络上不会被未授权的访问接触到你到信息
应用安全
应用的设计上抵挡各种攻击，防范各种风险
API 安全的目标
Confientiality 机密性
确保信息只被预期的用户访问
Integrity 完整性
防止未授权的创建、修改、删除
Availability 可用性
当用户需要访问 API 时，服务总是可用的
常见的 API 风险【 STRIDE】
1. Spoofing 欺骗
伪装成某人【例如，我不是系统管理员，但是我伪装成系统管理员，然后我想干什么干什么】
2. Tampering 干预
将不希望被修改的数据、消息或设置改掉【比如说修改法币订单的状态，用户把钱付了后，允许用户把订单的状态从未付款变为已付款，但是不允许用户在修改自己订单的时候，把其他人的订单也修改了】
3. Repudiation 否认
拒绝承认做过的事情【比如说用户需要退款，然后我们给它退款了，但是他拒绝承认已经退掉的款】
4. Information disclosure 信息泄漏
将你希望保密的信息批漏出来【如用户信息的泄漏】
5. Denial of service 拒绝服务
拒绝用户访问信息和服务【最常见的是DDOS 攻击，把你的服务压垮，把你的服务都堵住，让你没法为用户提供服务】
6. Elevation of privilegelege 越权
做了你不希望他能做的事
应对上述风险的安全机制
流控
解决了 拒绝服务 的 API 安全风险
流控可以防止用户请求淹没你的 API
认证
解决了欺骗的 API 安全风险
认证可以确保你的用户或者客户端真的是他【它】们自己
审计
解决了 否认的 API 安全风险
审计可以确保所有操作都被记录，以便追溯和监控
授权
解决了信息泄漏、干预、越权的 API 安全风险
授权可以确保每个针对 API 的访问都是经过授权的
加密
解决了信息泄漏的 API 安全风险
加密可以确保出入 API 的数据是私密的
API 安全.png
下面详细介绍各种安全机制
流控
- API 过载时拒绝多余的请求
- 限流机制生效后，请求应该立即被拒绝，并返回 HTTP 状态码 429【To Many Request】
认证
所谓认证就是验证用户身份是否合法的过程；
认证的作用是验证用户传进来的用户身份【比如校验用户传过来的请求头 Authorition】
而登录是 用户获取身份证明的一个过程【用于用户获取身份】
认证和登录的区别
- 在一段时间内【一天或者一个月，这个我们可以控制】，
登陆这个行为往往只发生一次，我们使用某个网站的时候，可能很长时间才去登陆一次，登陆的信息会保存一段时间 - 但是
认证这个行为是你每次请求去调业务逻辑都会去执行的一个动作 -
认证这个行为不管成没成功，或者有什么问题，都要往下走，它和登陆不一样 -
登陆一旦有问题，就断掉了，不会往下走；比如你登陆的用户名、密码填错了，就直接抛异常了，不会往下走了 - 但是
认证的时候，比如你传进来的用户身份有问题，或者你根本没有传用户身份，认证机制根本就没起作用，不管是什么情况，你仍然要往下走，需要在后面的审计记录去记录这次身份认证的结果是怎样的 - 最终的请求是否通过是由
授权来决定，不是由认证来决定的 - 你的认证机制可能根本没生效，你也不知道当前用户是谁，但是这个请求有可能是可以过的，比如说获取商品信息，那么这个服务请求不管用户登没登陆，用户都能看公司的商品，所以不管你的认证机制成功或者失败，生效还是没生效，都要往后走。 最后结果是怎么样的，由授权机制决定的，能不能访问是由授权来决定的
审计日志
-
审计应该放在认证之后，授权之前 - 在
认证之后，你才能知道这个请求到底是谁发出来的，谁在做这个事情 - 而放在
授权之前，那些被拒绝掉的请求在响应的时候也可以记录下来 - 如果把
审计放在认证之前，那么你是不知道请求是谁发的 -
审计用于记录谁在什么时间干了什么事情 -
审计日志一定要持久化 -
审计日志要做两次，一次是进来的时候做，一次是出去的时候做
授权
作用
授权用于做访问控制的
遵循的规则
要遵循最小的授权原则【一个用户只给他必须要的权限，不要的权限都不给他，什么时候有需要时再申请】
授权可能需要检测请求端的两个核心内容
- 是否已经进行了身份认证
- 是否有权限
做授权处理时需要考虑的两件事情
1. 你的请求是不是需要身份认证或者需要权限控制
- 有些请求是根本不需要权限控制的，比如说搜索，商品信息的查看，这些请求往往是没有权限控制的。也许用户感觉不错，就注册使用了
- 但是另外一些请求，比如说进行交易就是一定要有身份认证，一定要知道你是谁，才能下单
- 所以说第一个判断就是要判断一下当前这个请求是不是需要身份验证，如果需要身份验证，但是你当前用户没有认证，这个时候我们应该返回状态码401【即在要身份认证，但是认证失败】
2. 判断你有没有权限
- 如果没有权限，则返回403【403代表你身份认证成功了，但是不能去做请求的这个操作】
- 比如一个用户，用户密码填写对了，但是不能删除订单，删订单只有我们后台权限很高的管理员才能删除订单
HTTP 状态码 401和403的区别
- 401可以通过调整自己的身份信息来避免这个错误的【即把账户和密码改对】
- 但是403不一样，403对情况下，不管客户端在这个请求上做任何修改都不会导致这个403过去，只有一种情况，即访问用户必须向授权方要了权限，才能过这个403
权限控制的两种方式
【即检测用户是否有权限访问该 API】【不管是哪种，访问控制最终要控制的都是一个事情，就是这个用户能干什么】
1. ACL【Acess Control Lists】
- 是直接把用户和权限进行绑定【即A能做什么，B能做什么】
- 实现简单，但是管理复杂，如果有1000个用户，则需要配置1000个用户能干什么，不能干什么
- 简单易用，实现容易，无法满足复杂的业务需求，不易管理
2. RBAC 【Role Based Access Control】
引入角色概念，简化管理。开发起来相对 ACL 复杂
网友评论