访问控制体系, 服务可靠性保证, 异常告警响应流程设计

访问控制

API - Key

API Keys 是一种用于标识和验证请求API服务的应用程序或用户的一串字符

原理

原理简单, 调用 api 的时候携带的一串无标准定义的子串, 形式格式随开发人员随心所欲

本质上可以作为 token, password, access_code 等方式, 使用方面主打一个自由自在, 无标准无定义

其性能和安全性则也是因人而异

适用场景

较为简单的场景. 在不考虑稳定性安全性的内网场景下比如设置无限制内部凭证等情况下适用较多

一般主要用于快捷开发, demo, 脚本对接, sdk 等场景, 或者对接api场景下比如一系列开放平台

如 Google Maps, 微信公众平台, 阿里云开发者社区等

JWT

JWT (JSON Web Token) 基于2015年5月发布开放标准（RFC 7519）的认证协议，以紧凑自包含的形式提供给两方安全的信息传输

可使用 HMAC算法 或 RSA的公钥/私钥对 进行数字签名，确保仅发送者可以生成签名，且验证消息的完整性合法性

工作原理

JWT由三部分组成：Header(头部), Payload(有效负载) 和 Signature(签名)

Header（头部）　　通常由两部分组成：token的类型（即JWT）和使用的签名算法（例如HMAC SHA256或RSA）

Payload（有效负载）　　包含“声明”，声明是关于实体（通常是用户）和其他数据的陈述

Signature（签名）　　为了创建签名部分，你必须采用编码后的header和payload，使用header中指定的算法和密钥进行签名

样例

{header}.{payload}.{signature}

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

解析后的内容如下

{"alg": "HS256", "typ": "JWT"}

{"sub": 1234567890, "name": "John Doe", "iat": 1516239022}

性能拓展

轻量级, 无状态, 可快速解析, 对分布式友好, 易于服务端缓存

轻量级：作为一种轻量级的认证和授权方案，使用JSON格式进行编码和传输，相比传统的认证和授权机制来说，JWT的数据量相对较小
无状态：服务器不需要在自己的存储中维护会话。不会增加服务器的负担，也不需要对令牌进行持久化处理
快速解析：令牌结构相对简单，Base64编码。这使得JWT能够快速进行解析和验证，减少了网络延迟和处理时间
分布式友好：作为无状态的认证和授权方案，可便携的在多个服务之间进行传递验证，适用于分布式系统和微服务架构
缓存友好：在接受请求时就可完成验证，无需访问数据库发起网络请求，因此可以很好地与缓存机制集成使用，提高性能和扩展性

ps:

　　但是在高密集请求的场景下, 频繁的解密过程对于系统计算资源占用则会引入一些性能开销, 尤其是 RSA 这种复杂算法
　　可利用缓存解决此问题

安全可靠性

主要的可靠性保证取决于以下两个核心: 过期时间, 签名算法

JWT的安全性依赖于签名和加密的实施, 在安全性方面的亦可改进和注意的部分如下

1. 可采用更强加密算法（如 RSA 而不是 HS256）

2. 二次加密重要数据，以防止其被Payload中的信息泄露

3. 使用HTTPS协议来避免token被拦截

4. 设置合理的过期时间，以减少由于token泄露带来的风险

5. 验证服务的安全性和JWT实现的漏洞

适用场景

身份验证授权: 构建单点登录（SSO）系统、API身份验证和访问控制等
分布式系统：构建分布式系统和微服务架构。不同的服务通过传递令牌来验证和共享用户身份和授权信息
移动应用程序：基于标准的JSON格式，易于解析和使用, 可适用于移动应用程序中的身份验证和授权方案
缓存和性能优化：自包含用户身份和授权信息，可进行缓存和性能优化。仅通过令牌，可避免频繁地查询验证身份权限

缺陷

令牌包含内容过多导致长度较长时，会增加网络传输开销

令牌一旦签发，无法撤销，只能等待过期，增加安全风险 (可在功能开发层面解决这个问题)

令牌中的数据可能被解密，需要注意敏感信息的保护

SAML 2.0

SAML（Security Assertion Markup Language）安全断言标记语言, 基于XML的开源标准数据格式

始于2001年提出奠定1.0。其主要更新发布于2005年到2.0, 其主要为解决 SSO 问题

工作原理

SAML的原理基于信任关系，涉及三个主要角色：服务提供者(Service Provider，SP) 、用户(浏览器) 、和 身份提供者(Identity Provider，IdP)

具体的工作流程

当用户尝试访问服务提供者的资源时，服务提供者将重定向用户到身份提供者进行身份验证。
身份提供者验证用户身份后，生成一个安全断言，包含用户的身份信息和权限，然后将其发送回服务提供者
服务提供者根据安全断言决定是否授权用户访问资源

而具体的断言包含以下内容

主题（Subject）　　　　断言中的主题指的是用户的身份标识，例如用户的唯一标识符、用户名或电子邮件地址等

条件（Conditions）　　　断言中的条件定义了断言的有效期限和限制条件，例如断言的生存时间、使用范围等

身份提供者签名（Issuer Signature） 　　　　为了验证断言的来源和完整性，断言通常由身份提供者使用数字签名进行签名

被授权的权限（Authorized Privileges）　　　断言中可以包含授权信息，指示用户被允许访问的资源和执行的操作

为提供一个更为直观的说明, 下面是一段断言的示例

<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="_d71a3b8e45a4f9f6e710971520bbbf6e" IssueInstant="2021-07-01T12:34:56Z" Version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Issuer>https://identityprovider.com</Issuer>
    <Subject>
        <NameID>user@example.com</NameID>
        <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
            <SubjectConfirmationData NotOnOrAfter="2021-07-01T13:34:56Z" Recipient="https://serviceprovider.com/acs" />
        </SubjectConfirmation>
    </Subject>
    <Conditions NotBefore="2021-07-01T12:34:56Z" NotOnOrAfter="2021-07-01T13:34:56Z">
        <AudienceRestriction>
            <Audience>https://serviceprovider.com</Audience>
        </AudienceRestriction>
    </Conditions>
    <AuthnStatement AuthnInstant="2021-07-01T12:34:56Z">
        <AuthnContext>
            <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
        </AuthnContext>
    </AuthnStatement>
    <AttributeStatement>
        <Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <AttributeValue>user@example.com</AttributeValue>
        </Attribute>
        <Attribute Name="role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <AttributeValue>admin</AttributeValue>
        </Attribute>
    </AttributeStatement>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <!-- 签名信息 -->
    </Signature>
</Assertion>

断言包含的具体的内容

Assertion元素 根元素，标识整个断言
Issuer元素 指示断言的身份提供者
Subject元素 包含断言的主题，即用户的身份标识
Conditions元素 定义断言的有效期限和限制条件
AuthnStatement元素 包含有关用户身份验证的信息
AttributeStatement元素 包含有关用户属性和权限的信息
Signature元素 用于验证断言的来源和完整性的签名信息

性能拓展

性能较差:

XML 的数据承载主体本身着实无法用轻量来形容, 相比起oauth jwt 来说已经非常冗长
- SAML 2.0 允许使用压缩算法进对消息进行压缩处理, 尽可能的较少网络负载
且XML解析以及主体包含大量属性甚至还需被加密的情况下的计算资源占用也是不可忽视

拓展受限:

基于XML, 若传递过多信息会导致更加冗长
且处于信任的托管关系,被托管的数据拓展也会影响到身份提供者的存储性能压力

安全可靠性

使用 XML Encryption 为加密名称标识符、加密属性和加密断言提供元素（SAML 1.1没有加密功能）

在选择合适的加密方式的情况下, 技术本身安全性可以得到保证

但也会有XML 漏洞攻击外部实体注入漏洞的风险(XML External Entity Injection，简称 XXE)

XXE 攻击工作原理:

　　构造恶意的 XML 请求，在其中引入恶意外部实体，并触发应用程序对该 XML 进行解析。

　　当应用程序解析恶意的 XML 请求时，解析器会尝试加载和解析这些外部实体文件。

　　攻击者可以利用这一点来读取敏感信息、执行任意文件访问或者进行拒绝服务攻击等恶意行为

缺陷

性能较弱　　　　xml本身的冗长导致认证的信息主体较大, 传输占用和解码算力都要考虑其中

权限托管　　　　身份提供者需要保有用户信息和权限信息, 才可以提供给服务提供方, 需具备服务提供方的信息托管能力, 一定程度也限制了拓展性

XXE 风险　　　作为 XML 的基底就不可避免地有遭受XXE攻击的能力, 虽然也有办法可以规避, 比如禁止外部解析等

Oauth 2.0

OAuth 2.0 基于2012年的开放标准 (RFC 6749) 协定授权框架，即一系列的流程规范

允许第三方应用程序在用户的授权下，通过API安全地获取对用户在HTTP服务上的资源的访问权限

原理

OAuth 2.0的原理是通过访问令牌（Access Token）和授权代码（Authorization Code）来实现授权流程。

Access Token 　　访问令牌是客户端用来访问资源服务器上受保护资源的凭证

Authorization Code 　　授权代码是客户端向授权服务器请求访问令牌的中间凭证

授权流程由以下四种, 可满足丰富的场景需求

授权码（Authorization Code）
简化（Implicit）
资源所有者密码凭证（Resource Owner Password Credentials）
客户端凭证（Client Credentials）

以授权码流程为例，整个流程包括以下步骤：

（A）用户打开客户端以后，客户端要求用户给予授权

（B）用户同意给予客户端授权

（C）客户端使用上一步获得的授权，向认证服务器申请令牌

（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌

（E）客户端使用令牌，向资源服务器申请获取资源

（F）资源服务器确认令牌无误，同意向客户端开放资源

性能拓展

OAuth 2.0 作为流程规范, 底层基于HTTP 请求以及 JWT. 性能拓展的影响属性沿用 JWT相关因素

令牌持有机制也保证了后续得查询无需频繁的校验, 但是应对高频请求得场景下, 其主要受限于服务器性能和网络延迟和带宽

安全

OAuth 2.0通过访问令牌提供了额外的安全性，因此客户端不需要存储用户的用户名和密码, OAuth 2.0的安全性主要依赖于正确的实现和使用

如果不遵循OAuth 2.0的安全指导，可能会导致一些安全风险，如重定向域名欺骗、跨站脚本攻击、跨站请求伪造、访问令牌泄露等

为了保证OAuth 2.0的安全性，需要注意以下几点：

服务端必须验证客户端标识和重定向地址是否匹配，防止重定向域名欺骗
服务端必须对重定向地址进行检查，防止跨站脚本攻击
客户端必须使用state,nonce参数，防止跨站请求伪造以及校验认证码
客户端和服务端必须使用HTTPS协议，防止访问令牌泄露
客户端必须妥善保管访问令牌和刷新令牌，防止被盗用或滥用
服务端必须限制访问令牌的有效期和作用域，防止过度授权或长期授权

场景

社交登录　　　　用户可以使用他们的社交媒体帐户登录到其他应用程序，例如使用Google或Facebook登录

API访问　　　　开发人员可以使用OAuth 2.0来访问第三方API，例如使用GitHub API或Twitter API等各类开放平台

单点登录　　　　用户可以使用一个身份验证提供商登录到多个相关的应用程序，而无需多次输入凭证

授权访问　　　　应用程序可以请求用户授权访问其资源

移动应用授权　　移动应用程序可以安全地请求访问用户数据，如照片、联系人或位置信息

缺陷

复杂　　　　需要理解和实现多个角色、终端、流程和参数

易错　　　　需要遵循OAuth2的安全指导，防止重定向欺骗、跨站攻击、令牌泄露等

依赖　　　　需要依赖认证服务器和资源服务器的性能和可用性

OIDC

OIDC（OpenID Connect）是建立在 OAuth 2.0 协议之上的身份验证和授权协议

在 OAuth 2.0 的基础上增加了身份验证功能，通过在授权过程中返回 JWT 来验证用户的身份和信息传递

OIDC 提供了一种标准的方式来获取用户的基本信息，如姓名、邮箱等；OAuth 2.0 需要通过额外的接口来获取这些信息

工作原理如下

用户通过浏览器导航到网站或 Web 应用程序
用户单击登录并输入用户名和密码
RP（客户端）向 OpenID 提供商（OP）发送请求
OP对用户进行身份验证并获得授权
OP使用身份令牌（通常是访问令牌）进行响应
RP 可以向用户设备发送带有访问令牌的请求
UserInfo 端点返回有关用户的信息

PKCE

PKCE（Proof Key for Code Exchange）用于增强 OAuth2 授权码流程安全性的机制。它主要用于防止授权码颁发攻击

传统 OAuth2 授权码流程中，客户端应用程序通过重定向用户到授权服务器，用户进行身份验证并授权后

授权服务器将授权码返回给客户端应用程序, 客户端应用程序使用授权码向授权服务器请求访问令牌

而 PKCE 是为了应对在授权码流程中，授权码被拦截攻击的风险而提出的解决方案。

工作原理

客户端应用程序在发起授权请求之前，生成一个随机的 Code Verifier。
客户端应用程序计算 Code Verifier 的哈希值，得到 Code Challenge。
客户端应用程序将 Code Challenge 和其他授权请求参数一起发送到授权服务器。
授权服务器在返回授权码时，也会返回 Code Challenge。
客户端应用程序在向授权服务器请求访问令牌时，需要提供原始的 Code Verifier。
授权服务器会验证 Code Verifier 和之前返回的 Code Challenge 的匹配性，以验证请求的合法性。

PKCE 是一种增强 OAuth2 授权码流程安全性的机制，通过引入 Code Verifier 和 Code Challenge 来防止授权码被拦截攻击

它提供了一种在 无法安全存储客户端密钥 的情况下保护授权流程的方法

综合对比

技术	授权模式	特点	功能性	安全性	扩展性	性能	简易性	最佳适用场景
API Key	密钥, 客户凭证	简易, 自由	⭐	⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	简单API对接, 内网环境
JWT	签名	自包含, 简短, 无状态	⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	无状态身份验证
SAML2	XML(Assetion)	信任框架, xml	⭐⭐⭐	⭐⭐⭐	⭐⭐	⭐⭐	⭐⭐	单点登录(SSO)
OAuth2	授权码, 密码, 客户凭证, 访问令牌	流程规范, 场景丰富	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐	第三方应用授权
OIDC	授权码, ID令牌, 访问令牌	用户信息功能特化	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐	针对性身份验证和授权
PKCE	授权码	加密安全升级	⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐	⭐	安全要求较高, 无法保存凭证

权限控制

ACL - (Access Control List)

基于资源和用户/用户组的访问控制模型, 使用列表来定义每个资源上的用户或用户组的权限

当用户请求访问某个资源时，系统将检查资源的 ACL 列表来验证用户是否具有权限进行操作

适用于简单授权需求和较小规模的系统，特别是在资源数量和用户/用户组数量有限的情况下

RBAC - (Role-Based Access Control)

基于角色的访问控制模型，将权限分配给角色，然后将角色授予用户。用户通过角色来获取相应的权限

用户与角色关联，角色与权限关联。当用户请求访问某个资源时，系统会验证用户是否具有相关角色的权限

适用于复杂的组织结构和角色管理需求，特别是在管理 大量用户和角色 以及复杂的权限关系时

在此基础上引入角色组的概念, 利用角色分配和角色继承实现层级结构

ABAC - (Attribute-Based Access Control)

基于属性、策略和上下文的访问控制模型。使用属性、策略和上下文信息来决定访问权限

访问请求中包含属性和上下文信息，系统通过策略来评估这些属性和上下文信息，并根据策略判断是否授予访问权限

适用于需要动态访问控制和复杂授权需求的场景，特别是在需要根据 动态范围控制 和 属性决策 来管理访问权限时

FBAC - (Function-Based Access Control)

基于函数和规则的访问控制模型, 使用函数和规则来决定访问权限，根据条件和规则进行访问控制判断

适用于需要灵活的授权规则和动态访问控制需求的场景，特别是在需要根据特定条件和规则进行细粒度访问控制的情况下

PBAC - (Policy-Based Access Control)

RBAC 的表达能力有所欠缺，只能表达正向的访问控制，反向控制较难

ABAC 能较好地表达反向访问控制，但执行能力较差

PBAC 结合了RBAC 和 ABAC 的最佳特性以实现更多应用场景复杂且灵活的管理控制需求

对于正常来说在需求可预测的场景下的访问控制则不需要应用 PBAC

综合对比

技术	划分依据	特点	功能性	适配性	性能	简易度	最佳适用场景	相关产品
ACL	资源和用户/用户组	策略驱动, 资源粒度	⭐	⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	简单授权需求, 较小规模系统, 如文件系统	Linux/Unix 操作系统, 各类的对象存储服务 (oss, cos....)
RBAC	角色, 角色组	角色驱动, 层级分组划分	⭐⭐⭐	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	复杂组织结构, 角色管理需求, 亲和用户, ToB, ToC	K8s(>1.19), Django, Beego, Spring Security, 各类云方案(CAM, IAM, RAM...)
ABAC	属性、策略和上下文	策略驱动, 动态规则	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐	⭐⭐⭐	动态控制, 复杂授权需求, 定制化, ToB	K8s(<1.14), 百度云 IAM, 蚂蚁金服云安全管家
FBAC	函数和规则	逻辑驱动, 可编排	⭐⭐⭐⭐	⭐⭐⭐	⭐	⭐	动态授权, 细粒度访问控制, 高度定制, 特殊ToB	Istio, 低代码平台, 各种云函数产品 (AWS lamda, 华为云函数...)
PBAC	RBAC + ABAC	功能丰富, 复杂	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐	⭐	专项定制都难以满足的复杂场景, ToB服务提供商	Authing, axiomatics, OPA

服务可靠保障

进程保障

技术	简述	简易度	可靠性	功能丰富程度	社区活跃度
Upstart	事件驱动启动, 支持异步, 自动重启	⭐	⭐	⭐	内置
Supervisord	自动重启、进程管理、进程组管理、日志记录, 支持Web监控和管理进程	⭐	⭐⭐⭐	⭐⭐⭐	8.2k
runit	简单可靠, 自动重启, 服务监控, 需手动创建配置目录脚本文件	⭐⭐	⭐⭐⭐	⭐⭐	--
monit	全面的系统监控工具, 检测和自动修复故障，并提供了通知功能	⭐⭐	⭐⭐⭐	⭐⭐⭐	0.5k

流量负载

产品	简述	简易度	可靠性	性能	社区活跃度
Nginx	轻量级、高性能、可扩展性，大量用户和插件支持	⭐⭐⭐	⭐⭐⭐	⭐⭐	20k
HAProxy	高可靠性、性能出色，支持TCP/HTTP负载均衡	⭐⭐	⭐⭐⭐	⭐⭐⭐	4.3k
Traefik	自动化配置、动态刷新、云原生应用支持	⭐⭐⭐	⭐⭐⭐	⭐⭐	47.1k
Envoy	基于代理和Service Mesh的云原生应用支持	⭐⭐	⭐⭐⭐	⭐⭐⭐	23.6k

节点保证

由K8s保证

异常处理流程

1. 以日志驱动指标监控系统作为基础

2. 搭配大模型检测和预制规则来发现异常或发出预警

3. 发起异常流程催促各责任方进行事故处理

4. 清除异常后进行事件回溯和对应的收尾工作

完整详细的流程如下

数据采集, 监控预测
- 实时监测服务器、服务运行状态、资源利用率和性能指标
  - 服务器指标
    - cpu, 内存, 硬盘.... (>65%, >80% ....)
  - 服务指标
    - 异常请求数 ( >0/min)
    - 吞吐量 (> 250/s / >3000/m)
    - 状态码计数 (200 / 500 / 400 / 401 / 403 / 405)
    - 周期请求数 ( s / m / 30m / h / 3h)
    - 处理耗时中位数 ( > 500ms)
    - 中间件延时 (>10s)
    - web响应延时 (>15s)
    - ...
- 设计指标权重阈值制定预警规则
  - 当某些指标超过正常范围时触发预警通知
  - 预警触发后对预警指标动态提升权重等级
- 性能检测工具诊断相关瓶颈
  - 慢查询, 内存泄漏, 队列堆积等
- 标记日志收集落盘
  - 建立日志分析预警大模型
  - 使用历史数据和趋势分析来预测可能的异常情况，以便提前采取响应措施
异常诊断, 触发告警
- 识别异常归类, 命中细则执行告警通知
  - 触发告警事务, 进入告警处理流程
- 事故相关人员到位后, 通知收敛
  - 存在同类且大于人员接收能力范畴时, 对同类告警聚合, 以权重优先级提醒
  - 动态告警等级, 逐时间提升催促处理
故障处理, 恢复服务
- 自动化工具脚本处理常规异常
  - 服务重启. 数据库重载, 缓存重载等
- 人工处理
  - 灾备切换, 备份数据恢复, 服务迁移, 版本回退, 紧急发版等方式恢复服务
- 清除告警, 记录事件
事件回溯, 优化指引
- 记录问题根源, 解决方案, 事故影响
- 标记日志异常数据, 用于继续训练预警模型
- 设计持续集成自动化测试, 补充测试流, 丰富测试库
- 问题复现, 事故演练等

posted @ 2024-02-21 18:01 羊驼之歌阅读(22) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

坨之歌

The Bird of the Termes is my name, eating my wings to make me tame.

访问控制体系, 服务可靠性保证, 异常告警响应流程设计

访问控制

API - Key

原理

适用场景

JWT

工作原理

性能拓展

安全可靠性

适用场景

缺陷

SAML 2.0

工作原理

性能拓展

安全可靠性

缺陷

Oauth 2.0

原理

性能拓展

安全

场景

缺陷

OIDC

PKCE

综合对比

权限控制

ACL - (Access Control List)

RBAC - (Role-Based Access Control)

ABAC - (Attribute-Based Access Control)

FBAC - (Function-Based Access Control)

PBAC - (Policy-Based Access Control)

综合对比

服务可靠保障

进程保障

流量负载

节点保证

异常处理流程

完整详细的流程如下

公告