1. 安全原则(CIA)
- 机密性(Confidentiality)
- 完整性（Integrity）
- 可用性(Avaliability)
机密性：确保数据只被授权的主体访问，不被任何未授权的主体访问，就是不可见
完整性：确保数据只被授权的主体进行授权的修改，就是不可改
可用性：确保数据能够被授权的主体访问到，就是可读
通常，在互联网企业发展初期，可用性的优先级要高，如果涉及金钱交易的业务，则完整性的优先级较高，而涉及个人隐私的相关业务，则保密性的优先级较高。
2.安全原则(黄金法则)
- 认证(Authentication)
- 授权(Authorization)
- 审计(Audit)
大部分情况下，认证属于事前防御，授权属于事中防御，审计属于事后防御
3.密码学
密码学是黄金法则的落地基础技术
-
对称加密算法
算法 密码长度(bit) 加密强度 性能 版权 DES 56 弱 快 美国 3DES 168 中 慢 美国 IDEA 128 强 中 瑞士 AES 128 192 256 强 快 美国 SM1 128 强 未测试 中国(算法保密) SM4 128 强 未测试 中国(算法公开) -
非对称加密算法
非对称加密算法除了加密以外，还可以提供签名功能，也就是说，我们可以使用私钥加密，公钥解密，一旦接收方通过公钥成功解密，我们就能证明发送发拥有对应的私钥，也就能证实发送方的身份，私钥加密就是签名。
所有非对称加密算法，都是基于各种数学难题来设计的，他们的特点是：正向计算很容易，反向推到几乎无解。
非对称加密最大的优势是解决了秘钥分发的问题，在SSH登录、Git上传等场景中，我们都可以将自己的公钥上传到服务端，然后由客户端保存私钥。算法 加密强度 密钥生成性能 加解密性能 版权/专利 RSA 弱 慢 快 RSA公司 ECC 强 快 慢 争议中 SM2 强 快 慢 中国 -
散列算法
很多场景下，我们使用散列算法并不是满足加密的需求，而是利用它可以对任意长度的输入，计算出定长的ID
对散列的要求：不可逆性、鲁棒性(同样的消息生成同样的摘要)、唯一性(不存在两个不同的信息，能生成同样的摘要)
还有注意加盐，所谓“盐”，就是一串随机的字符，是可以公开的。将用户的密码“盐”进行拼接后，这样，即使两个用户设置了相同的密码，也会拥有不同的散列值。同时，黑客往往会提前计算一个彩虹表来提升暴力破解散列值的效率，而我们能够通过加“盐”进行对抗。“盐”值越长，安全性就越高。算法 长度 冲突概率 安全性 性能 MD5 128 中 中 中 SHA 160、256 低 高 慢 SM3 256 低 高 未测试
在使用的时候，你要记住下面这些内容：对称加密具备较高的安全性和性能，要优先考虑。在一对多的场景中（如多人登录服务器），存在密钥分发难题的时候，我们要使用非对称加密；不需要可逆计算的时候（如存储密码），我们就使用散列算法。 在具体算法的选取上，你只需要记住：对称加密用AES-CTR、非对称加密用ECC、散列算法用SHA256加盐。这些算法就能够满足大部分的使用场景了
3.身份认证
- 对外认证(单一场景下的认证)
- 对内认证(多场景下的认证)
- 单点登录(Single Sign On，SSO)
-
CAS(Central Authentication Service，集中式认证服务)
-
JWT(JSON Web Token)
JWT是一种非常轻量级的单点登录流程。它会在客户端保存一个凭证信息，之后在你每一次登录的请求中都带上这个凭证，将其作为登录状态的依据。JWT的好处在于，不需要应用服务端去额外维护 Cookie 或者 Session 了。但是，正是因为它将登录状态落到了客户端，所以我们无法进行注销等操作了。 -
OAuth(Open Authorization)
OAuth主要特点是授权，通过OAuth，用户在完成了认证中心的登录之后，应用只能够验证用户确实在第三方登录了。但是，想要维持应用内的登录状态，应用还是得颁发自己的登录凭证。这也就是为什么 QQ 授权后，应用还需要绑定你的手机号码。这也就意味着，应用是基于 QQ 的信息创建了一个自身的账号。 -
OpenID(Open Identity Document)
OpenID 和 OAuth 的功能基本一致。但是，OpenID不提供授权的功能。最常见的，当我们需要在应用中使用微信支付的时候，应用只需要收集支付相关的信息即可，并不需要获取用户的微信头像。
-
4.访问控制
-
访问控制模型
主体：请求的发起者。主体可以是用户，也可以是进程、应用、设备等任何发起访问请求的来源。
客体：请求的接收方，一般是某种资源。比如某个文件、数据库，也可以是进程、设备等接受指令的实体。
请求：主体对客体进行的操作。常规的是读、写和执行，也可以进一步细分为删除、追加等粒度更细的操作。 -
常见的访问控制模型
- DAC（Discretionary Access Control，自主访问控制）
DAC 就是让客体的所有者来定义访问控制规则，在DAC中，访问控制的规则维护完全下发到了所有者手上，管理员在理论上不需要对访问控制规则进行维护。因此，DAC具备很高的灵活性，维护成本也很低。相对的，尽管DAC降低了管理员的工作难度，但是会增加整体访问控制监管的难度，以至于安全性完全取决于所有者的个人安全意识。 - role-BAC（role Based Access Control，基于角色的访问控制）
role-BAC 就是将主体划分为不同的角色，然后对每个角色的权限进行定义，role-BAC是防止权限泛滥，实现最小特权原则的经典解决方案。试想一下，假如没有角色的概念，那么管理员需要给每一个用户都制定不同的权限方案。 - rule-BAC（rule Based Access Control，基于规则的访问控制）
rule-BAC 就是制定某种规则，将主体、请求和客体的信息结合起来进行判定，相比较来说，DAC是所有者对客体制定的访问控制策略，role-BAC 是管理员对主体制定的访问控制策略，而 rule-BAC 可以说是针对请求本身制定的访问控制策略。 - MAC（Mandatory Access Control，强制访问控制）
MAC 是一种基于安全级别标签的访问控制策略。在互联网中，主体和客体被划分为“秘密、私人、敏感、公开”这四个级别。MAC要求对所有的主体和客体都打上对应的标签，然后根据标签来制定访问控制规则。为了保证机密性，MAC不允许低级别的主体读取高级别的客体、不允许高级别的主体写入低级别的客体；为了保证完整性，MAC不允许高级别的主体读取低级别的客体，不允许低级别的主体写入高级别的客体。机密性不能低读、高写；完整性不能高读、低写。
访问控制 特点 关注对象 适用场景 案例 DAC 自主控制 关注客体的权限列表 由用户自主控制权限中 Linux: 各种C端应用，用户自己控制自己的内容是否可见 role-BAC 基于角色 关注主体的权限列表 管理员进行集中权限管控 公司内部系统，如ERP等，管理员设计角色，并将用户分配到角色 rule-BAC 基于规则 关注主体、客体、请求的属性 无法清晰定义角色的复杂场景 网络请求，主体和客体比较多，无法清晰划分角色 MAC 基于标签 关注主体、客体、请求的标签 能够对全部数据打上标签 政府系统，每一份数据和每个人都有明确的机密等级 - DAC（Discretionary Access Control，自主访问控制）
