身份验证和授权
身份验证
在安全领域中，身份验证是确认他是谁的过程
授权
通过授权机制，可以把主体映射到他可以进行的操作中
当一个主体通过身份验证后，我们将获得关于他的信息，这些信息可以帮助我们决定其可以进行的操作
对于单一的单块系统来说，应用程序本身会处理身份验证和授权
对于微服务架构，我们的目标是要有一个单一的标识且只需进行一次验证
常用的SSO（Single Sign-On，单点登录）实现
企业级领域常用的两种方式
SAML
OpenID Connect
用户->服务提供者->身份提供者->目录服务->身份提供者->服务提供者->用户
单点登录网关
下游服务如何接受主体信息的问题？？
如果你使用HTTP，可以把这些信息放到HTTP头上
一种虚假的安全感
内网与外网之间由单点登录网关做身份验证
内网之内，服务之间的调用是没有身份验证的
单点登录网关一定要简单，不能太复杂
细粒度的授权
单点登录网关可以提供相当有效的粗粒度的身份验证
例如：用户是否登录
细粒度的授权由每个服务提供者自己决定
单点登录网关获取主体属性，透传给下游服务提供者，服务提供者根据这些信息，做细粒度的授权
服务间的身份验证和授权
在边界内允许一切
内网环境，各个微服务之间的调用都允许
如果一个攻击者入侵了你的网络，攻击者就可以为所欲为
中间人攻击
边界内信任这种形式被大多数组织采用
发展初期，没有那么多精力做内网的身份验证和权限控制
需要意识到它的风险
HTTP（S）基本身份验证
在HTTP协议头上透传用户名和密码，服务端做身份验证
通过HTTPS加密
SSL证书管理问题
若经过代理服务转发，则不能在代理服务上缓存数据
使用这种方法，服务器只知道客户端有用户名和密码。用户名和密码泄露，则毫无办法了。
使用SAML或OpenlD Connect
内部服务也通过单点网关来做身份验证和授权
单点网关压力会很大
客户端证书TLS
服务端要管理TLS证书，比较复杂
当你特别关注所发数据的敏感性，或无法控制发送数据所使用的网络时，才考虑使用这种技术
HTTP之上的HMAC（Hash-based MessageAuthentication Code，基于哈希的消息码）
使用HMAC，请求主体和私有密钥一起被哈希处理，生成的哈希值随请求一起发送。然后，服务器使用请求主体和自己的私钥副本重建哈希值。如果匹配，它便接受请求
比HTTPS简单方便、系统开销小的方案
<font color="#c41230">APl密钥</font>
服务方给客户端分配API密钥做签名，然后在签名值的比较
API密钥重点关注的是对程序来说的易用性。相对于处理SAML握手，基于API密钥的身份验证更简单直接
由开发者自行决定使用方式，不受通信协议限制
代理问题
有一种安全漏洞叫作混淆代理人问题
已经登录的用户，查询其他账户的订单信息
用户登录成功了，通过了网关的身份验证
静态数据的安全
使用众所周知的加密算法
一切皆与密钥相关
如何管理密钥
使用单独的安全设备来加密和解密数据
密钥和加解密服务在一起
使用单独的密钥库，当你的服务需要密钥的时候可以访问它
密钥和加解密服务分开
按需解密
第一次看到数据的时候就对它加密。只在需要时进行解密，并确保解密后的数据不会存储在任何地方
加密备份
深度防御
防火墙
入侵检测（和预防）系统
IDS（Intrusion Detection Systems，入侵检测系统）
IPS（Intrusion Prevention Systems，入侵预防系统）
不同于防火墙主要是对外阻止坏事进来，IDS和IPS是在可信范围内积极寻找可疑行为
网络隔离
创建VPC（Virtual Private Cloud，虚拟私有云）进行网络隔离
操作系统
给操作系统的用户尽量少的权限
定期为你的软件打补丁
外部验证
由外部方实施的类似渗透测试这样的实验，模拟现实世界的意图
上面是一种评价安全效果的方法
