📚 课程目录第1章访问控制基础

1. 访问控制基础

访问控制这东西，我做了十几年安全，几乎每天都要跟它打交道。说白了，它就是决定“谁”能对“什么”做“哪些事”。你想想看，没有访问控制，系统里的数据就像敞开的门，谁都能进。那还谈什么安全？

它的目的很单纯：保护资源不被未授权访问。但实现起来，可没那么简单。我在早期一个项目中，就因为搞混了模型，差点让内部系统裸奔。嗯，从那以后我一直把基础知识放在第一位。

访问控制是信息安全的核心手段之一。它通过一套策略，限制用户对系统资源的访问。用大白话说，就是“门禁系统”——只不过这个门禁管的是数据、文件、API、网络端口等等。

核心三要素：主体（Subject）、客体（Object）、操作（Operation）。

没有这三位，讨论访问控制就是空中楼阁。记住：任何访问请求都可以抽象成一个三元组（主体，操作，客体）。

谁在发起访问？通常是一个用户，或者代表用户运行的程序、服务、进程。我在做金融项目时，习惯把“应用ID”也视为主体——因为很多API调用是机器对机器的，不能只看人。

被访问的资源。文件、数据库记录、网络端口、设备、微服务接口……一切需要保护的东西。有一次，我把“某个微服务的端到端调用链路”也列为客体，因为它的暴露可能造成内网探测。

主体对客体要做什么。最常见的：读、写、执行、删除、创建。不同模型对操作的命名和粒度不同。比如RBAC里可能存在“查看”、“修改”、“审批”等更细分的操作。

我的经验：千万别只给“读/写”两种操作。在真实业务里，“读”可能包含“部分字段可见”，而“写”分“插入”和“更新”。粒度太粗容易出权限漏洞。

说完三要素，我们看看业界怎么通过模型把它们组合起来。四种最经典的模型：DAC、MAC、RBAC、ABAC。我列个表格帮你快速对比。

这是最朴素的方式。文件的主人想给谁看就给谁看。你想想看，Linux 的 chmod 777 就是典型的 DAC。现实中很多内部泄密都是因为 DAC 太“自由”了。我曾经见过一个团队，大家互相给读写权限，最后审计时发现一个实习生能删掉生产数据库的配置文件——那真是吓出一身冷汗。

它不依赖用户意愿，而是全局标签。每个主体和客体都有安全等级（比如绝密、机密、公开），系统强制只有高等级主体才能读同等或更低等级的客体，写必须同等级或更高。说白了，它像“官方盖章”，你自己改不了。

我在涉密系统项目中用过 MAC，虽然管理成本高，但确实防得住跨等级的数据泄露。

这个模型大家应该不陌生。公司里你是什么角色（比如“经理”、“财务”、“工程师”），你就能拥有对应的权限。平时做企业应用，RBAC 是的主流。原因很简单：角色变化远比单独授权好管理。

不过它也有缺点：角色爆炸。我记得有个项目，业务太灵活，最后角色列表超过了200个，维护起来简直噩梦。

这个模型比较新，但很强大。它不看角色，而是看属性：你的部门、时间、地点、设备状态、当前风险等级……根据一堆条件组合判断是否放行。举个例子：“在北京的办公室，时间9:00-18:00，且使用的设备是公司笔记本电脑，才能访问财务系统”。

我最近给一个物联网平台设计权限，ABAC 简直完美匹配——设备温度和位置都能作为属性。但注意，ABAC 的策略定义和性能测试要做好，不然决策引擎会成为瓶颈。

注意：不是所有场景都适合ABAC。如果系统固定、角色稳定、权限需求简单，RBAC更轻量。我见过硬上ABAC导致上线延期的案例。

好了，这一节的主要概念都给你梳理了一遍。记住：三要素是骨头，模型是肉。不管你怎么设计权限，最终都要回到“谁对什么做什么”这个核心上来。我建议你动手画一张图，把自己的系统里主体、客体、操作列出来，看看目前用的是哪种模型。很多时候你写着写着就会发现——嗯，这里其实可以改进。

顺便说一句，后面我们会用大量实训来加深理解。但别急，先把基础打牢。知道不同模型的优缺点，你才选得对。