1. 访问控制基础：概念、目标与安全原则归纳总结

咱们直接进入正题。访问控制到底是个啥？
说白了，它就是系统里的一把锁——谁，能对什么资源，做什么操作。

1.1 三个核心概念

我在做第一个安全项目时，带我的老专家说了句让我记到现在的话：

三要素拆解

要素	术语	现实例子
谁？	主体（Subject）	用户、进程、API客户端
碰什么？	客体（Object）	文件、数据库表、内存区域
怎么碰？	操作（Operation）	读、写、执行、删除

我在项目中见过最典型的翻车案例：开发把 当作客体来保护，却忘了控制调用方进程这个主体。结果密钥本身没泄露，但恶意进程直接冒充合法主体，一样能把数据拖走。

1.2 访问控制的目标

你想想看，如果只说“控制谁可以访问”，那太笼统了。咱们得把目标拆成四个维度：

• 机密性（Confidentiality） —— 不该看的人看不到。我上次审计一家金融系统，发现他们日志文件居然对全服可读……嗯，那家后来紧急改了 ACL。
• 完整性（Integrity） —— 数据不能被未授权的人改掉。比如你的银行余额，就只允许核心系统写。
• 可用性（Availability） —— 授权用户不能被挡在门外。记得有一次我把防火墙规则配死了，自己都进不去服务器……（脸红）
• 问责性（Accountability） —— 谁干了什么，必须留下痕迹。没有审计的访问控制，就像没有摄像头的金库。

1.3 安全原则归纳（六条铁律）

下面这六条原则，是我在几十个安全评审中反复验证过的。每条背后都有血泪教训。

原则	核心思想	常见反例
最小权限（Least Privilege）	只给完成任务所需的最小权限	所有员工都配 root
职责分离（Separation of Duties）	关键操作必须多人协作	同一个人能审批且能打款
默认拒绝（Default Deny）	未明确授权的一律禁止	ACL 用了黑名单模式
开放设计（Open Design）	安全机制不依赖保密	用硬编码密钥做权限校验
安全域隔离（Domain Isolation）	不同安全级别的资源物理/逻辑隔离	内网和外网共用同一数据库
纵深防御（Defense in Depth）	多层控制，一层失效还有下一层	只依赖一个防火墙

我个人习惯把这些原则贴在工位上方的白板上。每次设计访问控制策略时，挨个过一遍——能避开大多数低级漏洞。

1.4 一张图理解核心逻辑

下面这张 SVG 把上述概念串起来了。你可以把它当作本章的“记忆锚点”：

1.5 代码示例：Django 中的最小权限 ACL

光说不练假把式。给你看一段我在实际项目中写过的 ACL 配置——就一句「默认拒绝」加上「白名单放行」：

from django.contrib.auth.models import Permission
from django.contrib.contenttypes.models import ContentType

# 默认拒绝：不给任何权限
user.user_permissions.clear()

# 只给「读取订单」权限
read_perm = Permission.objects.get(
    codename='view_order',
    content_type=ContentType.objects.get(app_label='orders', model='Order')
)
user.user_permissions.add(read_perm)

# 验证
if user.has_perm('orders.view_order'):
    print('可以读')
else:
    print('禁止访问')

我在评审代码时，最头疼的就是看到这样的写法：

1.6 避坑指南（来自真实事故）

• 千万别把权限设计留到开发后期。 我见过一个团队快上线了才想起加访问控制，结果不得不重构整个用户体系，延期一个月。
• 组权限不要搞成橡皮泥。 有个项目把“管理员组”给了几乎所有人，因为“方便调试”。上线后被审计出超范围授权，直接返工。
• 审计日志别等出事了再补。 嗯，这条我交过学费，就不展开说了……