|
|
|
|
|
|---|---|---|---|
| 第一级 |
|
|
|
| 第二级 |
|
|
|
| 第三级 |
|
|
|
| 第四级 |
|
|
|
| 第五级 |
|
|
|
01
|
|
|
|
|---|---|---|
| 身份鉴别 |
|
持续认证：
|
| 访问控制 |
|
动态最小权限：
|
| 安全审计 |
|
智能审计与UEBA：
|
| 数据保密性 |
|
|
-
ACL (Access Control List): 最早期的模型，像一份“白名单”，直接记录了哪个用户能对哪个文件进行操作。在系统用户和资源数量少时简单有效，但随着规模扩大，维护成本呈指数级增长，很快变得一团糟 。 -
RBAC (Role-Based Access Control): 引入了“角色”这一中间层，是目前企业应用最广泛的模型 。管理员不再直接给用户授权，而是给“角色”（如“财务经理”、“研发工程师”）授权，再把用户分配到不同角色。这极大简化了权限管理，易于理解和审计 。然而，RBAC的“静态”本质使其难以应对动态、复杂的业务场景。例如，无法简单实现“只允许用户查看自己所在部门的订单”这类依赖数据本身属性的控制。 -
ABAC (Attribute-Based Access Control): 被誉为“下一代”权限模型 。它的核心思想是“基于策略的动态决策”。授权不再是简单地看用户有什么“角色”，而是通过一个策略引擎，实时评估一系列“属性”是否满足预设策略。
* 用户属性: 角色、部门、职级、安全等级…
* 资源属性: 数据密级、所属项目、创建者、标签…
* 环境属性: 访问时间、IP地址、设备类型、地理位置…
* 操作属性: 读取、写入、删除、下载…
允许用户A读取文件B，当且仅当用户A的角色是“审计员”并且文件B的标签是“2025年Q3财报”并且当前时间是工作日并且用户A的IP地址在公司内网。这种灵活性和细粒度正是实现“X级等保”动态访问控制的基石 。
02
-
RBAC负责“静态”的业务职责划分： 定义稳定的、基于岗位职责的粗粒度权限。比如，“销售经理”角色拥有查看“销售报表”的权限。这构成了权限体系的骨架，清晰且易于管理。 -
ABAC负责“动态”的情境化细粒度控制： 在RBAC的基础上，通过策略叠加，实现对数据行、列级别以及特定场景的访问限制。
该平台希望实现：
-
销售人员只能看到自己所在区域（如“华东区”）的客户订单。 -
客服人员可以查看所有订单信息，但客户的手机号和地址等个人信息（PII）必须脱敏显示。 -
高级经理在非工作时间（如深夜）访问核心财务报表时，需要进行MFA（多因素认证）并触发高风险告警。
-
RBAC层面: 创建角色： 销售代表,客服专员,高级经理。为角色分配基础权限： 销售代表->访问订单系统；客服专员->访问订单系统；高级经理->访问订单系统、访问财务报表。 -
ABAC层面 (通过策略实现): 策略1 (行级数据权限): 规则: 允许当主体.角色 == "高级经理"时 读取资源.标签 == "核心财报" 条件: 环境.时间 不在 (22:00-07:00)或主体.会话.已通过MFA == True 效果: 经理在深夜访问时，访问请求会被拒绝，并重定向到MFA认证页面。认证通过后，会话中被标记 已通过MFA，后续访问即可通过。策略2 (列级数据脱敏): 规则: 允许当 主体.角色 == "客服专员" 时 读取 资源.类型 == "订单"
条件: True (允许访问)
附加操作 (Obligation): 对 资源.字段 属于 PII (如手机号、地址) 的数据，应用 脱敏函数。
效果: 客服在查询订单时，返回的数据中 13812345678 会被处理成 138****5678。
策略3 (动态风险控制):
规则: 允许当 主体.角色 == "高级经理" 时 读取 资源.标签 == "核心财报"
条件: 环境.时间 不在 (22:00-07:00) 或 主体.会话.已通过MFA == True
效果: 经理在深夜访问时，访问请求会被拒绝，并重定向到MFA认证页面。认证通过后，会话中被标记 已通过MFA，后续访问即可通过。
这种“RBAC搭骨架，ABAC精雕琢”的模式，既保证了权限体系的稳定性和可理解性，又赋予了系统应对复杂场景的灵活性。
-
建立行为基线： AI模型（如Isolation Forest, LSTM）通过学习历史操作日志，为每个用户建立一个“正常行为画像”（UEBA）。画像可以包括：常用登录地点、常用设备、活跃时间段、常规数据访问模式等。 -
实时风险评估: 当用户发起一次访问请求时，AI引擎会实时将当前请求的上下文（如IP、设备、时间、请求频率、数据敏感度）与用户的行为基线进行比对，并输出一个动态的“风险分”。 -
动态权限决策: 这个“风险分”会作为一个关键的 环境属性，被送入ABAC策略引擎（如OPA或Casbin）。策略可以这样设定： 允许，如果 risk_score < 0.5 需要MFA，如果 0.5 <= risk_score < 0.8 拒绝并告警，如果 risk_score >= 0.8
一名研发人员通常在白天于上海办公室访问代码库。某天凌晨3点，一个来自海外IP的请求，试图用他的账户下载整个核心代码仓库。
-
传统RBAC: 只要账户密码正确，且角色是“研发”，访问就会被允许。 -
AI动态授权: -
AI引擎检测到： 时间异常、IP地址异常、操作量异常。 -
计算出极高的 风险分（如0.95）。 -
ABAC策略引擎根据 risk_score >= 0.8的规则，立即拒绝该请求，并向安全运营中心发送高优先级告警。
-
Casbin: 一个轻量级、支持多种访问控制模型的权限管理库 。它以其强大的适配器生态和对多种编程语言的支持而闻名，可以轻松嵌入到现有应用中。Casbin的核心是 PERM模型（Policy, Effect, Request, Matchers），通过配置文件定义访问模型和策略规则，非常灵活 。因其易用性和广泛的社区支持，在很多企业中被用于实现RBAC和ABAC的结合 。 -
Open Policy Agent (OPA): 一个通用的、与平台无关的策略引擎。OPA通常作为中心化的决策服务部署，在微服务架构中尤其受欢迎（例如作为Kubernetes的准入控制器）。它使用一种名为 Rego的声明式语言来编写策略，功能极其强大，可以处理复杂的JSON/YAML结构化数据，非常适合云原生环境下的统一策略管理。
-
如果你的需求是为单个应用或一组紧密耦合的服务快速集成灵活的权限控制，Casbin 是一个很好的起点。 -
如果你的目标是在整个企业（尤其是复杂的微服务和云原生环境）中建立一个统一、解耦、标准化的策略决策中心，那么OPA 是更具战略性的选择。
03
|
|
|
|
|
|---|---|---|---|
| 基础信息
|
event_id |
uuid-v4 |
|
timestamp |
2025-11-01T14:30:05.123Z |
|
|
event_type |
DATA_ACCESS |
|
|
| 主体属性
|
subject.id |
user-12345 |
|
subject.role |
["finance_manager", "region_lead"] |
|
|
subject.attributes |
{"department": "sales", "geo": "APAC"} |
|
|
| 操作信息
|
action.type |
READ |
|
action.result |
ALLOWED |
|
|
| 资源属性
|
resource.id |
order-98765 |
|
resource.type |
Order |
|
|
resource.attributes |
{"sensitivity": "PII", "owner": "user-54321"} |
|
|
| 环境属性
|
context.ip |
202.96.209.133 |
|
context.device_id |
mac-abc-def |
|
|
context.geo |
Shanghai, CN |
|
|
| 策略信息
|
policy.id |
policy-data-access-001 |
|
policy.decision_factors |
{"risk_score": 0.95, "reason": "abnormal_time"} |
|
|
| 数据指纹 | data_hash |
sha256-xxxxx |
|
-
保留期限: 《网络安全法》和等保2.0三级要求明确指出，网络日志的保留时间 不少于六个月（180天）。对于等保四级或更敏感的系统，建议保留一年或更久 。 -
存储安全: 日志本身也是敏感数据，必须保证其存储的安全性与完整性。 -
防篡改: 采用WORM（Write-Once Read-Many）存储介质，或将日志哈希值上链（区块链存证），确保日志的原始性和不可否认性 。 -
分层存储: 依据日志的新旧程度进行冷热分离。例如，最近30天的热数据存储在高性能可快速检索的Elasticsearch中，更早的冷数据归档到成本更低的对象存储或磁带库中 。 -
合规检查: 定期（如每季度）进行自动化合规检查，扫描审计日志，验证访问控制策略是否被正确执行，是否存在越权访问、权限滥用等情况，并自动生成合规报告。
-
正常行为: 员工A是一名数据分析师，他每天的工作是查询近一个月的销售数据，每次查询约1000行，并制作报表。 -
异常行为: 周五晚上23:00，员工A开始密集查询历史长达三年的客户联系方式数据。 半小时内，发起了超过50次查询，累计下载数据量超过50万行。 访问的数据敏感等级为“高度机密”，远超其日常工作所需。 -
AI审计发现: 系统检测到 时间异常、查询频率异常、数据量异常、数据敏感度异常等多个维度的偏离。尽管每次单独的查询都“符合”该员工的RBAC角色权限，但这一系列行为构成的“操作序列”与他的历史行为模式严重不符。 系统综合判断这是一个高风险的“数据聚合与外泄”行为模式，立即生成告警，并可配置自动执行“熔断”操作，例如临时冻结该账户或限制其网络访问。
04
-
从 静态授权 转向 动态授权。 -
从 基于身份 转向 基于情境。 -
从 被动合规 转向 主动预警。 -
从 人工管理 转向 智能驱动。
