RBAC：角色和权限管理

1） RBAC的宗旨和原则

目标：使访问具有可管理性，可验证性，并且数量最少，以保护金钱/PII和合规性（GDPR/AML/PCI/ISO）。
原则：Least Privilege· Need-to-Know· Duties Separation （SoD）· Zero Trust· Revocability（快速召回）·Auditability（可证明性）。

2）权利和角色的分类法

• 数据："READ"，"WRITE"，"EXPORT"，"DELETE"，"MASKED_READ"（PII的默认值）。
• Операции: `APPROVE_WITHDRAWAL`, `CHANGE_FRM_RULE`, `KYC_DECISION`, `SANCTIONS_OVERRIDE`.
• Админ: `ROLE_UPDATE`, `USER_PROVISION`, `SECRET_ROTATE`, `BREAK_GLASS`.
• 集成："API_CALL："、"WEBHOOK_SIGN"、"SERVICE_CONFIG_UPDATE"。

• Core (сквозные): `employee_basic`, `viewer_internal`, `auditor_privacy`.
• Доменные: `support_agent`, `vip_manager`, `payments_ops`, `aml_officer`, `kyc_operator`, `fraud_analyst`, `rg_specialist`, `bi_analyst`.
• 系统/人员：'devops_admin'、'dba_admin'、'service_account_'、'read_only_prod'。
• 特权（通过PAM/JIT）："break_glass_admin"，"prod_db_jit_editor"。

3）角色设计（角色工程）

1.资源清单：系统/表/内联网、数据类（Public/Internal/Confidential/Restricted/Highly Restricted）。
2.用户故事按功能：谁在做什么和为什么（purpose）。
3.Mapping Task → permissions：每个功能的最低设置。
4.角色分组：一个角色=一个责任域；避免"超级角色"。
5.SoD测试：不兼容性检查（例如，"payments_ops" ≠ "fraud_rule_admin"）。

6.飞行员和测量： 给临时限制组,收集审计跟踪.

7.转化：每个角色的变化都是通过CAB与changelog。

4）RBAC ↔ ABAC ↔ SoD相互作用

RBAC响应"原则上谁可以"，ABAC响应"在什么条件下"（环境，地理，设备/MDM，时间，KYC级别，"purpose"）。
SoD禁止危险的角色组合，并且需要4眼才能采取关键行动。
实践：默认情况下，角色为PII提供了MASKED_READ；未掩盖的访问需要"purpose"+JIT属性和积极的ABAC策略解决方案。

5）多重性和地理背景

Tenant-scope：角色与租赁/品牌/司法管辖区相关（'role：payments_ops@EEA'）。
Geo-keys：个别加密密钥和按区域访问段（EC/UK/……）。
粒度：通过"region_code"（RLS）列和玩家管辖权进行过滤。

6）Row/Column-Level安全性和掩饰

• RLS（行）：仅访问其国家/品牌/团队的记录。
• CLS（列）：敏感字段可伪装访问；没有掩饰-仅具有"pii_unmask"+"purpose"特权。

sql
CREATE POLICY rls_tx
ON dwh. transactions
USING (region_code = current_setting('app. region'));

SELECT
CASE WHEN has_priv('pii_unmask') THEN email ELSE mask_email(email) END AS email_view
FROM dwh. users;

7) JIT, break-glass и PAM в RBAC

JIT：tiket的临时特权角色（15-120分钟）；自我评估；全面审计。
破玻璃：使用MFA+第二次确认和会议记录进行紧急访问；Security+DPO后续评论。
PAM：保密存储，会话代理，密码/密钥轮换。

8）角色生命周期（SOP）

SOP-1： 创建/更改角色

1.域所有者的请求→任务列表→ mapping permissions → SoD支票→飞行员→ CAB →版本+文档。

SOP-2： 请求和准入

1.申请（IDM/ITSM）具有"purpose"和→ SoD/司法管辖区的自动验证 →数据所有者批准+Security（对于Restricted+）→签发（通常是JIT）→注册。

SOP-3： 召回/离岸公司

触发因素：解雇，角色变更，不活动>30/60天，JIT到期。
自动召回和日志。

SOP-4： 重新认证

每季度，所有者确认仍然需要用户角色；该系统消除了"悬挂"权利。

9）角色矩阵示例（片段）

10）工具与实现（模式）

角色目录为代码：存储库+CI验证器changelog中的YAML/JSON。
中央IdP/SSO：SCIM-provigening，"group → role"组映射。
策略决策点：具有上下文属性的策略引擎（ABAC）。
Secrets/KMS： 按键隔离环境/区域/tenant。
数据网关：用于DWH/BI/导出的单个掩蔽/审核层。
SIEM/SOAR：相关性"ROLE_UPDATE"/"READ_PII"/"EXPORT_DATA"，自动滴答。

11）审核和日志

Обязательные события: `ROLE_ASSIGN`, `ROLE_REVOKE`, `ROLE_UPDATE`, `BREAK_GLASS`, `JIT_GRANT`, `READ_PII`, `EXPORT_DATA`, `PAYMENT_APPROVE`, `KYC_DECISION`.

要求：WORM副本、散列链、数据包签名、每个事件中的"purpose"/"ticket_id"、超时同步。

12）度量标准和KPI/KRI

覆盖：RBAC下的系统百分比≥ 95％。
SoD violations: = 0;尝试分配不兼容的角色-自动块。
JIT利率：≥ 80%的涨幅与JIT一样。
离开TTR：召回权利≤ 15分钟。
Masked reads ratio： ≥ 95%的PII转诊是伪装的。
Recertification：100%的角色每季度确认一次。
签名：100%带签名/日志的出口。

13）RACI（集合）

14）支票单

在创建角色之前

• 描述用户故事和"purpose"
• 资源和数据类别列表
• Mapping minimum permissions
• SoD验证/冲突
• 屏蔽策略和RLS/CLS
• 重新认证计划和所有者

在授予访问权限之前

• 固定"purpose"和期限
• SoD/司法管辖区/MDM/MFA执行
• 默认掩码,JIT升级时
• 日刊和修订日期包括在内

15）频繁的错误和反模式

"Superroli"具有广泛的权利而不是小型域名。
无需掩盖即可直接访问PII和"purpose"。
"PAYMENT_APPROVE"/"KYC_APPROVE"缺少SoD/第四只眼睛。
延长临时权利"永远"。
在dev/stage中复制prod数据。
无签名和日志的不透明出口。

16）实施路线图

第1至第2周：资源清单/数据分类；草稿角色矩阵；SoD表。
3-4周：RBAC作为代码（存储库），IdP 组/SCIM，ABAC引擎（基本属性：环境/地理/MDM/时间），JIT/PAM，DWH/BI的掩蔽层。
第2个月：重新认证，离岸自动化，RBAC/SoD/ABAC违规的SOAR-Alerta，出口日志/WORM。
月3+：属性扩展（设备风险，KYC级别），可用性bias审计，成本优化和常规的平板操作。

TL;DR

强大RBAC=小域角色+属性条件（ABAC）+SoD和JIT/PAM+掩蔽以及RLS/CLS+严格的审核和重新认证。这减少了泄漏/滥用的风险，加快了审计，并使平台保持在隐私和合规要求的范围内。