身份认证与访问控制：统一身份认证（SSO/OAuth2.0）、多因素认证（MFA）实施、基于角色的访问控制（RBAC）设计、权限分级与审计

聊到流程自动化系统的安全，身份认证和访问控制绝对是第一道防线。我见过太多项目，业务逻辑写得漂亮，结果在权限这块翻了车。说白了，你连门都看不好，里面东西再值钱也没用。

这一章，我们重点拆解四个核心模块：统一身份认证、多因素认证、基于角色的访问控制，以及权限分级与审计。嗯，都是实战中绕不开的硬骨头。

统一身份认证：SSO 与 OAuth 2.0

先说说统一身份认证。你想想看，一个流程自动化系统，往往要对接十几个甚至几十个外部服务。如果每个服务都单独搞一套用户名密码，那运维人员光记密码就得疯掉。

我个人习惯用 SSO（单点登录） 来解决这个问题。用户只需要登录一次，就能访问所有授权的系统。实现 SSO 的主流协议，目前就是 OAuth 2.0 和 SAML。对于现代系统，我更推荐 OAuth 2.0，因为它更轻量、更适合移动端和 API 场景。

核心要点：OAuth 2.0 不是认证协议，是授权协议。它解决的是「用户允许第三方应用访问其资源」的问题，而不是「用户是谁」的问题。真正的用户身份认证，通常由 OpenID Connect（OIDC）在 OAuth 2.0 之上完成。

我在项目中遇到过这样一个坑：团队直接拿 OAuth 2.0 的 Access Token 当用户身份凭证用。结果呢？Token 泄露后，攻击者直接拿到了所有 API 的访问权限。正确的做法是，用 OIDC 的 ID Token 来确认用户身份，Access Token 只用来调用资源。

来看一个简单的 OAuth 2.0 授权码流程示例：

// 客户端向授权服务器发起请求
GET /authorize?response_type=code
    &client_id=YOUR_CLIENT_ID
    &redirect_uri=https://yourapp.com/callback
    &scope=openid profile email
    &state=random_state_string

// 用户授权后，授权服务器返回授权码
// 客户端用授权码换取 Access Token
POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=AUTHORIZATION_CODE
&redirect_uri=https://yourapp.com/callback
&client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET

// 返回 Access Token 和 ID Token
{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "id_token": "eyJhbGciOiJSUzI1NiIs..."
}

避坑指南：我曾经见过一个系统，state 参数直接写死成固定值。这等于把 CSRF 攻击的大门敞开了。state 参数必须每次随机生成，并且在回调时严格校验。

多因素认证（MFA）实施

光有 SSO 还不够。密码泄露是常态，你想想看，多少人的密码是 123456 或者生日？所以，多因素认证（MFA） 必须安排上。

MFA 的核心思想是：至少使用两种不同类型的认证因素。通常分为三类：

  • 知识因素：你知道的东西，比如密码、PIN 码
  • 持有因素：你拥有的东西，比如手机、硬件 Token、U 盾
  • 固有因素：你是什么，比如指纹、人脸、虹膜

我个人建议，流程自动化系统的管理员账号、以及涉及敏感操作（如审批大额支付、修改核心配置）的账号，必须启用 MFA。普通用户至少也要支持 MFA，最好强制启用。

实施 MFA 时，有几个细节要注意：

  • 备用码：用户丢失手机怎么办？一定要提供一次性备用码，让用户提前保存好。
  • 记住设备：别让用户每次登录都输验证码。可以允许用户「信任此设备 30 天」。
  • 降级攻击：我曾经遇到过，攻击者通过重置密码流程绕过了 MFA。嗯，这里要注意，密码重置流程也必须走 MFA 验证。

警告：不要使用短信验证码作为唯一的 MFA 方式。短信可能被拦截、SIM 卡可能被克隆。优先推荐 TOTP（基于时间的一次性密码）或硬件安全密钥（如 YubiKey）。

基于角色的访问控制（RBAC）设计

认证搞定了，接下来就是授权。RBAC 是目前最成熟、最常用的授权模型。说白了，就是「用户 -> 角色 -> 权限」的映射关系。

我设计 RBAC 时，一般遵循这几个原则：

  • 最小权限原则：只给用户完成工作所需的最小权限。多一个都不给。
  • 职责分离：比如，发起审批的人和审批通过的人，不能是同一个角色。
  • 角色继承：高级角色可以继承低级角色的权限，但反过来不行。

来看一个典型的 RBAC 数据模型：

-- 用户表
CREATE TABLE users (
    id INT PRIMARY KEY,
    username VARCHAR(50) UNIQUE NOT NULL,
    email VARCHAR(100),
    enabled BOOLEAN DEFAULT TRUE
);

-- 角色表
CREATE TABLE roles (
    id INT PRIMARY KEY,
    name VARCHAR(50) UNIQUE NOT NULL,
    description VARCHAR(200)
);

-- 权限表
CREATE TABLE permissions (
    id INT PRIMARY KEY,
    name VARCHAR(100) UNIQUE NOT NULL,
    resource VARCHAR(100) NOT NULL,  -- 例如：order, payment
    action VARCHAR(50) NOT NULL      -- 例如：create, read, update, delete
);

-- 用户-角色关联
CREATE TABLE user_roles (
    user_id INT REFERENCES users(id),
    role_id INT REFERENCES roles(id),
    PRIMARY KEY (user_id, role_id)
);

-- 角色-权限关联
CREATE TABLE role_permissions (
    role_id INT REFERENCES roles(id),
    permission_id INT REFERENCES permissions(id),
    PRIMARY KEY (role_id, permission_id)
);

我在项目中遇到过，有人把权限直接硬编码在代码里。结果业务一变，就得改代码、重新部署。正确的做法是，把权限配置做成动态的，支持后台管理界面调整。

个人经验：角色名称要起得直观。别用什么「ROLE_ADMIN_001」这种编号。直接用「系统管理员」「审批专员」「只读用户」这种一看就懂的。你想想看，运维人员半夜排查问题时，看到清晰的角色名能省多少时间。

权限分级与审计

最后，说说权限分级和审计。这是很多系统容易忽略的部分。

权限分级，就是把权限按敏感程度分成不同等级。比如：

等级 描述 示例 审批要求
L1 普通操作 查看报表、查询订单 无需审批
L2 敏感操作 修改订单、发起审批 直属上级审批
L3 高危操作 删除数据、修改系统配置 部门负责人 + 安全团队审批
L4 核心操作 修改权限、导出全量数据 多级审批 + MFA 验证

审计，说白了就是记录谁在什么时间、从哪个 IP、做了什么操作。这不是为了事后追责，而是为了及时发现异常行为。

我曾经处理过一个案例：某员工凌晨 3 点登录系统，批量导出了客户数据。审计日志第一时间触发了告警，安全团队在 10 分钟内就冻结了账号。如果没有审计，数据泄露了可能过好几天才发现。

审计日志至少需要记录以下字段：

  • 用户 ID 和用户名
  • 操作时间（精确到毫秒）
  • 源 IP 地址
  • 操作类型（增、删、改、查）
  • 操作对象（哪个资源、哪条记录）
  • 操作结果（成功/失败）
  • 请求详情（参数、User-Agent 等）

注意：审计日志本身也要防篡改。我建议使用「写前日志」模式，先写日志再执行操作。日志文件要设置只追加权限，并且定期备份到独立的日志服务器。有条件的话，可以用区块链或哈希链技术保证日志的完整性。

嗯，身份认证与访问控制这块，内容确实不少。但说白了，核心就三件事：确认你是谁（认证）、确认你能做什么（授权）、记录你做了什么（审计）。把这三件事做好了，系统的安全性就有了基本保障。

← 上一章 📖 返回目录 下一章 →