认证的各类方式

补充一下认证方式,一般是由三大类方式及其组合实现:

What you are:
比如人的生理特征(指纹、面部识别、虹膜、声纹、DNA等)

What you know:
古代机关开启方式、密码、动态指令、预设安全问题、最近和谁聊天、最近几次变动的密码、最近几次登录地址等

What you have:
身份证,医保卡,银行U盾牌,手机短信/电话语音发送验证码

但有一些就不太会好判断归属:
1、公安局开的身份证明或CA颁发给机构的证书,应该是“你有啥”,但很多时候直接被用于“你是谁”
2、图形动态验证码,用于判断“你是人不是机器”,这个算是“你是谁”的简单版本?

令牌内容
令牌不需要带太多的信息,但要满足一些基本要求:
1、令牌颁发机构标识
2、令牌被授予机构、APP、服务或网站标识
3、令牌类型(资源访问令牌、刷新令牌等)
4、令牌可访问的资源类型(头像、昵称、二维码等)
5、令牌有效时间范围
6、令牌颁布机构签名和时间戳
7、数据组织方式其实用Json 或 编码过的字符串都可以
这样,三方就都可以快速验证令牌有效性。

数据权限
数据权限确实很多时候只能系统自己处理,很难跨行业通用,甚至同一行业不同机构也不尽相同。比如两个看似比较通用的场景:
1、当机构架构分为多级时,上级机构能看到下级哪些数据,平级之间能看到那些数据,下级机构能看到什么数据,各行业各类组织互不相同。如果只用功能权限的思路去解决这个问题,容易将功能权限弄得十分复杂。
2、此外就是用户情况比较复杂,比如除了组织架构、岗位、职级外,还有职业证书相关权限控制、客户业务办理关系、项目组组成、项目组轮班,加上审核、稽核、多级质控等功能,仅是功能权限也是力有不逮。
而且,近些年来,各公司对数据权限和数据安全的要求都越来越高、越来越严格了。

凭证
感觉中文的“凭证”指的内容,比Credentials范围广很多。比如:
有时候,网页提示“请输入登录凭证”,说的就是用户名密码
有时候,请下载云主机“临时凭证”,说的就是登录证书
有时候,请出示入场凭证,说的就是一张狗牌

尤其是证书是否算凭证,感觉有些想不清楚。比如:下面的算凭证吗?
1、域控认证,Windows凭证管理器
2、Linux服务器可以通过ssh证书直接访问
3、一些云厂商可以申请临时ssh证书,允许远程访问
4、IOS程序发布时,需要开发者申请APP证书,并签名才能上传发表
5、接入云SDK时,需要申请AppId 和 SecretKey
6、TCP通讯时,采用TLS双证书双向加密

客户端敏感数据加密
对于客户端敏感数据加密的问题:
1、客户端对敏感信息加密,在通用浏览器、开放网络环境下,其实意义不大。如果一位黑客有能力干掉HTTPS通讯加密或者伪装为服务网站的话,替换掉网站前端代码也不是一件难的事情,这样无论如何加密信息都没有任何用途。同时,在客户端、服务的,这些敏感信息其实都有原文的,如果贡献了这两个地方,黑客可以同时获取明文和密文,所以加密也没啥用。
2、对于安全要求特别高,采用特殊通信协议,特殊信道,特殊设备、特殊浏览器的情况下,对于特别敏感的信息,进行二次加密是有必要的。因为设备和软件都难以得到,即使信道被监听,通信加密被破解,也要尽量拖延敏感信息被破解。

字证书有什么具体应用
1、机构、网站、身份认证
2、APP开发者认证
3、可执行程序开发者认证
4、控件开发者认证
5、API认证
6、文档的电子签章证书
7、大家自己搭建开发环境时有时需要自签名证书
其实还有很多咯。

除了顶级CA之外,其实CA也分等级的,这就涉及到了证书链。
此外,CA还要维护黑名单,吊销一些还在有效期之内的证书。

数据验证
之前只是零零散散有了一些想法,也落地了。但看完今天老师的讲解,感觉落地的很难看。

数据校验这部分,回顾了一下,我们真的做了很多,但十分十分的零散。根据各种要求,包括架构、运维、数据安全、数据合规要求、数据脱敏、敏感数据加密,每年都要折腾个几轮。此类代码横跨了文章中提到的全部层,实现方式从单纯的编码规范,到各层编码,到切面,到流水线扫描,到Jar包,到中间件、到持久化层验证,都有零散涉及。如果能尽量统一到 Bean Validation处理,就不至于每次加个要求,都要一通大改了。

Leave a Reply

Your email address will not be published.

*