焱老师带你学习架构 基础篇（八）安全

前记

在当今的数字化时代，安全性已成为软件架构设计中不可忽视的核心要素。随着网络攻击本领的不停演进，Java应用作为企业级开辟的主流选择，其安全性问题尤为突出。本文将深入探讨如何在Java应用架构中融入安全性设计，确保系统在面对各种潜伏威胁时仍能保持稳定与可靠。
1 . 安全简介

安满是个很大的话题，此中服务器安全，系统安全，网络安全等超多板块，由于本人主要是做后端的可能更多的是从系统安全的角度思量问题，如果把系统按照办理方案分其实只要分为：
认证，授权，凭证，加密。
2 . 认证

2 . 1 认证根本概念

其实认证本质上就是你是谁的问题。
比如HTTPS中使用SSL证册本质上就是。
2 . 2 常见的认证方式

2 . 2 . 1 通信通道的认证

类似于SSL/TLS证书基于协议通道层认证。常见于HTTPS，WSS等
2 . 2 . 2 通信协议的认证

指的是HTTP协议里的标注实现方案。主要流程类似于如图。

还有其他方式：
1 . Digest：把用户名跟密码加严后加密发送，但此方法并不安全。轻易被中间人攻击。
2 . Bearer：基于OAuth协议完成。会在授权里详细说。！！！此方法很重要，在笔者地点的公司是做国际化项目，与google，facebook，teams等超级多的国外大公司接触过API，他们的用的OAuth2根本都基于本方法完成。
3 . HOBA：基于CA证书来认证。
2 . 2 . 3 通信内容的认证

就WebAuthn（类似于虹膜，指纹，人脸等生物信息）认证。流程如下：

3 . 授权

3 . 1 授权验证方式

3 . 1 . 1 RBAC

这是最最常见的授权方式，主要在toB场景使用，比如内网系统的权限设计，SAAS系统内等场景内应用较多。
3 . 1 . 2 OAuth2验证

3 . 1 . 2 . 1 OAuth2使用场景

此场景主要是面向第三方应用，一般三方业务系统都须要集成QQ，微信等常见登录方式，但微信跟QQ的账密是不可能给到三方系统，那么三方系统是如何验证这个用户就是A呢？就是通过OAuth。
3 . 1 . 2 . 2 OAuth2流程图

这是OAuth标准实现的授权码模式，也是笔者在做Google，Facebook，等众多三方渠道最最常用的模式。
此中请求授权地址也可以通过服务端来做，这样做的好处是可以加风控计谋或者控制，而不是把控制权转移给客户。
4 . 凭证

凭证主要是为相识决HTTP协议是无状态的问题。
4 . 1 凭证范例

4 . 1 . 1 Cookie-Session

4 . 1 . 1 . 1 原理

在用户做登岸时，使用一个随机字符串来表示用户的登录信息。
比如生成一个uuid，以此uuid作为key存储在redis里，value存储用户的id等账户须要数据。
4 . 1 . 1 . 2 优点

安全，由于账户数据仅仅只是存储在服务端，而通过特定标识符来关联，全部相对安全。
4 . 1 . 1 . 3 缺点

对服务端压力较大。
如果使用读扩散，会由于存在强耦合导致出现单点问题。
如果使用写扩散，会导致数据划一性出现问题。比如生成一个session，但服务器本地还没有收到该session数据的关照，会出现划一性问题。
4 . 1 . 2 JWT

4 . 1 . 2 . 1 构成

JWT由header（请求头），payload（负载），Signature（签名）构成。
Header：主要定义了令牌范例以及签名算法。
Payload：业务信息。（可以由服务端生成，后由客户端拓传即可）。
Signature：验证此t令牌是否由本身生成。
4 . 1 . 1 . 2 优点

减少服务端压力，且是最贴合HTTP协议本身的无状态。
4 . 1 . 1 . 3 缺点

令牌难以自动失效，令牌在生成时可以指定失效时间，但由于我们想自动失效，较为复杂，如果能接受一定的容错，最好把令牌的失效控制在redis里较为合适。
只能携带有限数据，由于一般网络容器对HTTP协议的header长度有限制，但一般环境下不会出现这种问题。
5 . 加密

5 . 1 常见的加密算法

hash摘要：类似于MD5方式的不可逆加密。
对称加密：加密和机密是一样的秘钥。
非对称加密：公钥加密，私钥解密或私钥加密，公钥解密。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。