5.凤凰架构：构建可靠的大型分布式系统 — 架构安全性

第5章　架构安全性
	计算机系统的安全，不仅仅是指"防御系统被黑客攻击"这样狭义的安全，还至少应包括以下问题的具体解决方案：
		1.认证(Authentication)
			系统如何正确分辨操作用户的真实身份。
		2.授权(Authorization)
			系统如何控制一个用户该看到什么数据，操作哪些功能/span>
		3.凭证(Credential)
			系统如何保证它与用户之间的承诺是双方当时真实意图的体现，是准确的、完整且不可抵赖的。
		4.保密(Confidentiality)
			系统如何保证敏感数据无法被包括系统管理员在内的内外部人员所窃取、滥用/span>
		5.传输(Transport Security)
			系统如何保证通过网络传输的信息无法被第三方窃听、篡改和冒充/span>
		6.验证(Verification)
			系统如何确保提交到每项服务中的数据是合乎规则的，不会对系统稳定性、数据一致性、正确性产生风险/span>

5.1　认证
		认证(你是谁)、授权(你能干什么)和凭证(你如何证明)可以说是一个系统中最基础的安全设计。账户和权限的管理往往由专门的基础设施来负责，
	如微软的活动目录(Active Directory, AD)或者轻量目录访问协议(LDAP)。

	5.1.1　认证的标准
		架构安全性的经验原则：以标准规范为指导、以标准接口去实现。安全涉及的问题很麻烦，但解决方案已经很成熟，对于99%的系统来说，在安全上
	不去做轮子，不去想发明创造，严格遵守标准，就是最恰当的安全设计。

		主流的三种认证方式：
			1.通信信道上的认证
				你和我建立通信连接之前，要先证明你是谁。在网络传输场景中的典型应用就是基于ssl/tls传输安全层的认证。
			2.通信协议上的认证
				你请求获取我的资源之前，要先证明你是谁。在万维网场景中典型的应用是HTTP协议的认证。
			3.通信内容上的认证
				你使用我提供的服务之前，要先证明你是谁。在万维网场景中典型应用是基于web内容的认证。

		1.HTTP认证
			HTTP协议的通用认证框架，要求所有支持http协议的服务器，在未授权的用户意图访问服务端保护区域的资源时，应返回401 Unauthorized
		的状态码，同时应在响应报文头里附带以下两个分别代表网页认证和代理认证的Header头之一，告知客户端应采取何种方式能代表访问者身份的凭证
		信息：
			WWW-Authenticate: realm=
			Proxy-AUthenticate: realm=

			接到该响应后，客户端必须遵守服务端指定的认证方案，在请求资源的报文头中加入身份凭证信息，由服务端核实后通过后才会允许该请求正常
		返回，否则返回403 Forbidden错误。请求报文头应包含以下Header项之一：
			Authorization:
			Proxy-Authorization:

			HTTP认证框架提出认证方案是希望能把认证"要产生的身份凭证"的目的与"具体如何产生凭证"的实现分离开来，无论客户端通过生物信息(指纹、
		人脸)、用户密码、数字证书亦或者其他方式生成凭证，都属于如何生成凭证的具体实现，都可以包含在http谢雨预设的框架之内。

			HTTP Basic 认证是一种主要以演示为目的的认证方案，也应用于一些不要求安全性的场合。Basic 认证产生用户身份凭证的方法是让用户
		输入用户名和密码，经过base64编码"加密"后作为身份凭证。大概过程：
			a)浏览器收到服务端的响应如下：
				HTTP/1.1 401 Unautthorized
				WWW-Authenticate: Basic realm="example from icyfenix.cn"

			b)弹出对话框，要求用户提供用户名和密码

			c)用户输入用户名和密码，如用户名"admin"，密码"123456"，浏览器会将字符串"admin:123456"，经过base64编码，然后发送给服务端；
				GET /admin HTTP/1.1
				Authorization: Basic base64(xxx)

			d)服务端接收到请求后，解码后检查用户名和密码，合法就返回"/admin"的资源，不合符就返回 403 Forbidden错误。

 
			除了Basic认证，还有其他的认证方案：
				1.Digest
					HTTP摘要认证，可视为Basic认证的改良版。针对base64明文发送的危险，Digest认证把用户名和密码加盐(一个被称为Nonce的
				变化值作为盐值)后通过 MD5/SHA 等哈希算法取摘要发送出去。但是这种认证依然是不安全的。

				2.Bearer
					基于 OAuth 2 规范来完成认证。

				3.HOBA(HTTP Origin-Bound Authentication)
					一种基于自签名证书的认证方案。基于数字证书的信任关系主要有两类模型：一类采用CA层次结构的模型，由CA中心签发证书；另一种
				是以IETF的 Token Binding 协议为基础的 OBC(Origin Bound Certificate, 原产地证书)。

			HTTP 认证框架中的认证方案是允许自行扩展的，并不要求一定由RFC规范来定义，只要用户代理能够识别这种私有的认证方案即可。

		2.Web认证
			如果用户想访问信息系统中的具体服务，肯定是希望身份认证是由系统本身的功能去完成的，而不是由HTTP服务器来负责认证。这种依靠内容而不是
		传输协议来实现的认证方式，在万维网被称为"Web认证"，由于实现形式上登录表单占了绝对主流，因此通常也被称为"表单认证"。

			2019年3月，万维网联盟(w3c)批准了由FIDO(Fast IDentify Online)领导起草的世界首个web内容认证的标准"WebAuthn"。
		WebAuthn彻底抛弃了传统的密码登录方式，改为直接采用生物识别(指纹、人脸、虹膜、声纹)或者实体密钥(以USB、蓝牙、NFC连接
		的物理密钥容器)作为身份凭证，从根本上消灭了用户输入错误产生的校验需求和防止机器人模拟产生的验证码需求等问题，甚至可以省略了表单界面。

			WebAuthn 规范覆盖了 "注册"和"认证"两大流程。注册分为如下步骤：
				1.用户进入系统的注册页面，这个页面的格式、内容和用户注册时需要填写的信息均不包含在WebAuthn标准的定义范围；
				2.当用户填写完信息，点击提交信息的按钮，服务端首先暂存用户提交的数据，生成一个随机字符串(在规范中称为Challenge)和
				用户UserID(在规范中称为凭证ID)并返回客户端；
				3.客户端的WebAuthn API接收到Challenge和UserID后，把这些信息发给验证器(Authenticator)。验证器可以理解为用户设备上的
				TouchID、FacdID、实体密钥等认证设备的统一接口；
				4.验证器提示用户进行验证，如果支持多种验证设备，还会提示用户选择一个想要使用的设备。验证的结果是生成一个密钥对，由验证器存储
				私钥、用户信息以及当前的域名。然后使用私钥对Challenge进行签名，并将签名结果、UserID和公钥一起返回给客户端；
				5.浏览器将验证器返回的结果转发给服务器；
				6.服务器核验信息后，检查UserID与之前发送的是否一致，并用公钥解密后得到的结果与之前发送的Challenge作对比，一致即表明注册
				通过，由服务端存储该UserID对应的公钥。

			登录流程：
				1.用户访问登录页面，填入用户名后即可点击登录按钮；
				2.服务器返回随机字符串Challenge、用户UserID;
				3.浏览器将Challenge和UserID转发给验证器；
				4.验证器提示用户进行认证操作。由于在注册阶段验证器已经超出了该域名的私钥和用户信息，所以如果域名和用户都相同的话，就不需要
				生成密钥对了，直接以存储的私钥加密Challenge，然后返回浏览器；
				5.服务端接收到浏览器转发来的被私钥加密的Challenge，并以此前注册时存储的公钥进行解密，如果解密成功则宣告登录成功。

			WebAuthn 采用非对称加密的公钥、私钥代替传统的密码，这是非常理想的认证方案。私钥是保密的，只有验证器需要知道它，连用户本人都
		不知道，也就没有人为泄露的可能。公钥是公开的，可以被任何人看到或存储。公钥可用于验证私钥生成的签名，但不能用来签名，除了得知私钥外，
		没有其他途径能够生成可被公钥验证为有效的签名，这样服务器就可以通过公钥是否能解密来判断用户的身份是否合法。

			WebAuthn 还解决了传统密码在网络传输上的问题，无论是否在客户端进行加密以及如何加密，对防御中间人攻击都没有意义的。更值得夸赞的是，
		WebAUthn为登录过程带来了极大的便利性，不仅注册和验证用户体验十分优秀，而且彻底避免了用户在一个网站上泄露秘密，所有使用相同密码网站都
		受到攻击的问题，这个优点使得用户无需再为每个网站想不同的密码。

	5.1.2　认证的实现

 
5.2　授权
		授权这个概念通常伴随着认证、审计、账号一同出现，并成为AAAA(Authentication、Authorization、Audit、Account)。安全领域中所说的授权就更具体
	一些了，通常涉及以下两个相对独立的问题：
		1.确保授权的过程可靠
			对于单一系统，授权的过程比较可控，以前语境上提到授权，实质上都是讲访问控制，但理论上两者应该是分开的。在涉及多方的系统中，授权的过程则是一个比较困难
		却必须严肃对待的问题：如何既能让第三方系统访问到所需的资源，又能保证其不泄露用户的敏感数据呢用的多方授权协议主要有 OAuth 2 和 SAML 2.0。

		2.确保授权的结果可控
			授权的结果用于对程序功能或者资源的访问控制，成理论体系的权限控制模型有很多，譬如自主访问控制(DAC)、强制访问控制(MAC)、基于属性的访问控制(ABAC)、
		还有最常用的基于角色的访问控制(Role-Based Access Control，RBAC)。

	5.2.1　RBAC
		所有访问控制模型，实质上都是在解决同一个问题："谁(User)拥有什么权限(Authority)去操作(Operation)哪些资源(Resource)"。

		用户(User) =>  => 角色(Role) =>  => 许可(Permission) =>  => 资源(Resource)

		许可是抽象权限的具体化体现，权限在RBAC系统中的含义是"允许何种操作用于哪些资源上"，这句话的具体实例即为"许可"。提出许可这个概念的目的与提出角色的目的是完全
	一样的，只是为了更抽象。角色目的为解耦用户与权限之间的多对多关系，而许可为的是解耦操作与资源之间多对多的关系。


来源：enlyhua
                                                        
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！