#博客大赛# 斗胆尝试浅入门之BAC
什么是BAC
计算机行业内小伙伴可能或多或少了解OWASP（开放式 Web 应用程序安全项目），OWASP Top 10 是面向开发人员和 Web 应用程序安全性的标准意识文档。它代表了对 Web 应用程序最关键的安全风险的广泛共识。它会定期更新一份数据统计名为“OWASP Top 10”，这份统计在业界非常有影响力；
最新一期是2021年Top 10，对比上一次的2017年，变化非常明显，我们来关注下Top1。
A01:2021 – 损坏的访问控制
“A01:2021-Broken Access Control从第五位上升,它也被称为授权，它定义了 Web 应用程序如何向某些用户而不是其他用户授予对内容和功能的访问权限。
”
94%的应用程序都经过了某种形式的破坏访问控制的测试。映射到Broken Access Control的34个CWE（Common Weakness Enumeration）在应用程序中出现的次数比任何其他类别都多。
BAC定义
控制失效或者不足，导致未经授权的信息的泄漏、修改或损坏所有资料，或执行超出用户权限的业务功能的现象；
业界也不乏这样的案例；那为什么去破坏访问控制呢？是因为无所事事？好玩？还是说有别的意图，也许初衷并非如此，但是最终还是为了利益，就像这句话：
“不管你愿不愿意承认，历史上没有一场仗是因为爱和正义打起来的，所有的流血背后，深层次的原因都是经济.
”
小菜篡改下这段话，映射到安全领域：
“不管你是否同意，历史上没有一次安全事件是因为好玩，所有的攻击，深层次的原因都是利益.
”
为什么预防BAC
BAC案例
业界案例
业界比较有名的10大金融案例，参考References
01 新西兰证交所连续一周遭受DDoS攻击导致交易中断
02 欧洲某银行遭遇史上最大规模的DDoS攻击
03 世界最大加密货币交易所接连发生数据泄露事故
04 保险巨头First American 8.85亿份敏感财务记录曝光
05 金融巨头加鼎银行290万用户资料遭内部员工窃取
06 美国第一资本银行遭黑客窃取1.06亿条用户敏感数据
07 恶意软件Carbanak针对银行和金融机构发起攻击，涉案金额超10亿欧元
08 两大黑客集团合计窃走10亿美元加密货币
09 黑客组织利用银行APP漏洞非法获利2800余万元
10 境外APT组织利用恶意软件攻击我国互联网金融平台卷走150万美元数字资产
亲民案例
小菜带来几个交付过程中的安全问题案例，供大家浅浅感受一下。
案例一
场景：某A银行项目的核心业务之一：支持我自己名下卡账户直接转账，尤其是跨币种之间转账，方便用户抓住时机，快速投资，如下执行预转账流程：
从上述流程图可以看出，Orderid属性（预转账单），从BE兜转到UI后，原封传递给BE。
现象：3rdP 在调用外部核心系统执行转账时，缺乏对Orderid的归属校验；
结果：用户A携带非本人accounts生成的Orderid进行转账时，依然可以转账成功；
影响：不同用户之间存在横向越权安全问题，导致个人资产未授权转移；
直接原因：Orderid属性从安全态变为非安全态（想一下为什么）3rd服务未对来自外部系统的数据做严格校验导致了问题；
根本原因：对外部传入数据的校验不够严格导致了横向越权。
案例二
某B银行项目的增加业务之一：支持用户使用自己的手机号或身份证号 绑定/解绑 指定银行账号对应的二维码，提升转账效率；
现象：绑定或者解绑过程，核心模块缺乏对手机号/身份证号的归属校验；
结果：用户A可以绑定或解绑非本人二维码数据；
影响：不同用户之间存在横向越权安全问题，个人正常交易受阻，银行交易量受损；
直接原因：缺少逻辑判断，识别手机号和身份证号归属正确性；
根本原因：对外部传入数据的校验不够严格导致了横向越权。
案例三
场景：某电信网优系统的环境，客户通过该系统获取网络质量统计报表，制定每个季度网络优化策略。续性中断。
现象：业务人员无法按时获取统计报表数据；
结果：客户因为缺乏报表数据，不能输出有效的策略数据，导致既定规划没办法高效实施；
直接原因：系统全局配置被某些业务人员误操作导致不能提供；
根本原因：业务人员权限过大，可以操作到业务权限之外的其他功能。
预防BAC目的
一问： 预防背后的想保护什么呢？
一答：
“核心价值资产”，资产的价值不一定是对应的购买价格，也可能是某些提供电子交易业务的服务器资源，服务器不可用（DDoS）会导致直接的收入损失和客户的商誉损失。
二问： 不预防BAC带来的坏处
二答：
从长期来看，对一个企业，BAC一旦发生极有可能是严重或致命的打击，预防BAC无论是重要性或者必要性上来说都是需要优先考虑的事。举几个例子感受下：
对金融行业：疏忽对交易数据的准确性和正确性校验，会带来什么后果呢； 对医疗行业：忽视个人敏感数据的保护，比如明确存在病例等信息，一旦泄漏，会导致什么后果呢； 对电商行业：没有限制购买热门商品的数量问题，引发黄牛业务滋生，又会带来什么问题呢；
如何预防BAC
通过上述案例，预防BAC有比较成熟的做法：以核心资产为圆心，以系统的数据流为承载进行拆解，一般有如下三种核心方式并行防护：
“认证：合法认证通过的用户才能接入系统;
”
“授权：具备一定权限的用户才能操作相关业务;
”
“加密：加密保护核心资产数据的传输通道和存储点.
”
今天，小菜给大家唠叨一篇预防BAC问题核心手段之一：授权（后续系列再聊认证，加密相关）。
授权定义---来自原始INI技术文档
“Authorization occurs after an entity’s identification and authentication have occurred to determine exactly what they are allowed to do. Authorization is implemented through the use of access controls.
”
解读
“授权发生在实体的标识和身份验证（认证）之后，以确定它们被允许做什么。授权通过使用访问控制来实现。 它表达意思是主体访问客体时，需要明确访问门禁。
”
授权流程三要素：
主体：主动的实体，需要访问的资源
客体：被动的实体，被访问的资源
授权：增/删/改/查/执行等
访问控制策略之授权
关于授权模型，常见有两大类：
类型1: DAC
类型2: Non-DAC（MAC，RBAC，RAC，ABAC）；
小菜尝试用亲身经历过的一些例子加以阐述：
模型 1: 自主访问控制（DAC）
DAC定义---来自identity management institute
“Discretionary Access Control is a model of access control based on access being determined by the owner of the target resource. The owner of the resource can decide who does and does not have access, and exactly what access they are allowed to have.
”
解读
“自主访问控制(DAC)是一种基于目标资源所有者确定的访问权限的访问控制模型。资源的所有者可以决定谁有访问权，谁没有访问权，以及他们到底被允许拥有什么访问权。
”
例子
在Linux系统中，万物皆文件，文件权限属性包含：owner权限，group权限，other权限，详细参考文末reference链接
| file name | owner | privileage |
|---|---|---|
| abc | root | -rw-r--r-- |
| abc.sh | root | -rwxr--r-- |
| bcd | appservice | -rw-r--r-- |
| bcd.sh | omservice | -rwx------ |
文件abc归属用户即所有者是root，root用户创建了这个abc文件，且当前的权限是644，意味着，root可以读与写，但是与root同组的其他用户和跨组的用户均可读取abc；
bcd.sh文件，归属用户即所有者是omservice，当前权限是700，意味着，omservice本人可以读写并执行该脚本文件，除此之外对非root的其他用户均不可见，比如appservice用户登录系统后无法看到bcd.sh。
在微软Windows的NTFS(New Technology File System)文件系统使用也是DAC模型。
模型 2: Non-DAC
2.1 强制访问控制（MAC）
MAC定义---来自identitymanagementinstitute
“Mandatory Access Control is a model of access control in which the owner of the resource does not get to decide who gets to access it, but instead access is decided by a group or individual who has the authority to set access on resources.
”
解读
“强制访问控制(Mandatory Access Control)模型，强调资源的所有者不能决定谁可以访问它，而是由有权设置资源访问权限的组或个人决定访问；一般会引入tag，这些tag都是预先定义好的，每个客体和主体都有一个或多个tag，系统根据分配的tag确认访问权限。
”
例子1
为了方便说明，我们来定义4种客体的tag标签，分别对应不同安全等级的资源：
| tag-机密 | tag-私有 | tag-敏感 | tag-公开 |
|---|---|---|---|
| A1 | B1 | C1 | D1 |
| A2 | B2 | C2 | D2 |
| A3 | B3 | C3 | D3 |
定义4种主体的tag标签，分别对应不同用户等级：
| tag-机密许可 | tag-私有许可 | tag-敏感许可 | tag-公开许可 |
|---|---|---|---|
| R1 | R2 | R3 | R4 |
管理员分配权限时需要遵从如下原则：
1 给R1归属用户分配A1，A2客户的权限，可访问A1，A2；
2 没有给R1分配A3权限，不可访问A3；
3 无法向R2归属用户分配A1，A2，A3客户的权限。
例子2
SeLinux（Security-Enhanced Linux）是MAC绝佳实践，这个话题展开说比较复杂，后续有机会专门再展开学习，当前简单总结如下：
“当一个主体Subject（如一个程序）尝试访问一个目标Object（如一个文件），SELinux 安全服务器SELinux Security Server（在内核中）从策略数据库Policy Database中运行一个检查。基于当前的模式mode，如果 SELinux 安全服务器授予权限，该主体就能够访问该目标。如果 SELinux 安全服务器拒绝了权限，就会在 /var/log/messages 中记录一条拒绝信息。
”
关于SELinux技术文档入门请参考：References
总结
MAC模型默认禁止，即默认开启安全限制，它使用默认拒绝原则； 如未特殊授予用户访问数据权限，则系统默认拒绝和用户访问相关数据； MAC从实现上更安全，比起DAC，但是灵活性和可扩展性就非常受限了。
2.2 基于角色的访问控制（RBAC）
RBAC定义---来自原始技术文档
“Role-Based Access Control is a model of access control that, similar to MAC, functions on access controls set by an authority, rather than by the owner of the resource. The difference between RBAC and MAC is that access control in RBAC is based on the role of the individual accessing the resource.
”
解读
“基于角色的访问控制是一种访问控制模型，它类似于MAC，作用于由权限设置的访问控制，而不是由资源的所有者设置。 RBAC和MAC的区别在于，RBAC中的访问控制是基于访问资源的个人所扮演的角色；一般来说会使用角色或组实现权限设置，比如具体用户归属于某个角色，用户就具备角色下的权限。
”
例子
回顾下案例3，系统所有权限掌控在一个角色手中，等价于把全部鸡蛋放到一个篮子，一旦发生有利益竞争时，该角色可以完成从0-100的所有操作；我们一起尝试分析下案例3中该如何划分角色？
从管理/维护/业务的角度出发，采用统一的集中授权管理，执行分权，可以划分出4类角色：admin/secadmin/secauditor/sysadmin，职责分别如下
| role | permission |
|---|---|
| admin | 具备业务管理+用户管理所有操作权限 |
| secadmin | 权限管控中心，负责角色增删改查及赋权，但是不具备行权能力 |
| secauditor | 日志审计员，用于查看系统中增删改查行为的详细日志 |
| sysadmin | 系统运维角色，部署升级服务，服务管理等权限，无业务操作权限 |
创建一套role-based access control分权管理机制去合理划分业务并规范操作；能够实现“三权分立”相互制约权力的效果，这样系统安全性会大大提高。
总结
RBAC最大特点：主体通过其归属角色获取资源；而角色基于业务属性区分范围，比如业务操作员，运维人员，日志审计员等；
RBAC在频繁更改人员的动态环境中非常方便；管理员只需要将新用户添加到合适的角色中即可快速授予权限；删除权限，也只是删除对应角色的用户即可。
2.3 基于规则的访问控制（rBAC）
RAC定义
“rules-based access control uses a set of rules, restrictions, or filters to determine what actions can or cannot occur on a system. It includes granting subjects access Objects or permission to perform an operation.
”
解读
“基于规则的访问控制使用一组规则、限制或过滤器来确定系统上可以或不可以发生特定操作。它包括授予主体对对象的访问权或执行操作的权限。RAC模型显著特点他们具备适用于所有主体的全局规则。
”
例子
之前参与过一个项目有个非常合适的例子，它的目的是尽量的隐藏对外暴露的端口，最佳实践采用iptables(软防火墙)；iptables本质上就是一种包过滤型防火墙，以下是配置的过滤规则
iptables -A FORWARD -s 192.168.1.11 -j REJECT
iptables -A FORWARD -s 192.168.0.0/24 -j ACCEPT
上述规则作用是接受除了“192.168.1.11”之外所有192.168.0 .0～192.168.0 .255网断数据；iptables功能远不止于此，想了解更多，参考references。
总结
RAC模型非常广泛地应用在防火墙技术。
2.4 基于属性的访问控制（ABAC）
ABAC定义---来自原始技术文档
“Attribut-based access control is an access control method that allows or denies operations requested by a subject to an object based on the assigned attributes of the subject, the assigned attributes of the object, environmental conditions, and a set of policies associated with those attributes and conditions.
”
解读
“基于属性的访问控制，根据主体的指派属性、客体的指派属性、环境条件和与这些属性和条件相关的一组策略，允许或拒绝主体对客体所请求的操作。
”
属性可以是和用户、网络、设备的任何特征，比如：
1 用户属性可以是：身份，归属部门，使用的设备型号等；
2 网络属性可以是：本地网络，无线网络，内部网络，广域网络等；
3 设备类型可以是：防火墙，代理服务器，Web服务器，数据库服务器等。
例子
没有真实在项目上过的例子，但是听到过隔壁项目有类似的需求，如：
“允许用户使用平板电脑或智能手机访问APP”
“禁止用户使用低于iOS13的系统访问APP”
“法律黑名单用户禁止发起任何银行转账”
回归敏捷
每一种模型都采用不同的方法来控制主体如何访问客体，经过上述的理论加案例，应该能够明显发现各有特点：这些模型有的内置在不同操作系统内核中，有的通过合适代码架构融入到业务的核心模块中，提供合适的、精确的访问控制。
项目交付中的AC (此AC非彼AC)
在项目上，如何选择合适的Access Control，需要PO & BA & TL & InfoSec 根据业务需求、安全需求，结合项目在市场的地位、受众、风险等因素，进行决策使用何种方式，
简单整理几种模型特点供参考：
| 名字 | 优点 | 缺点 | 典型应用 |
|---|---|---|---|
| DAC | 模型非常灵活，适合个体用户单机使用 | 数据量较大时，不建议采用 | 文件权限控制 |
| MAC | 权限管控非常惊喜，适合高敏感企业 | 灵活性和扩展性较差 | 军工，银行等机构 |
| RBAC | 以权限职责划分，快速高效进行权限管理 | - | 网优系统，论坛系统 |
| rBAC | 规则往往容易上手且维护成本非常低 | 应用范围较窄 | 防火墙 |
| ABAC | 属性定制灵活，方便定制过滤规则 | 应用范围较窄 | SDN网络 |
References
OWASP https://owasp.org/Top10/zh_CN/A01_2021-Broken_Access_Control/
Finance Cases https://www.secrss.com/articles/25933
IMI https://identitymanagementinstitute.org/access-control-types-and-models/
SELinux https://en.wikipedia.org/wiki/Security-Enhanced_Linux
Iptables https://wiki.archlinux.org/title/iptables
本文由 mdnice 多平台发布