05 | 访问控制：如何选取一个合适的数据保护方案？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入介绍了数据保护方案的选择，重点围绕身份认证、授权、审计和访问控制的基本概念和原理展开。文章首先讨论了身份认证的核心问题是身份管理，以及单点登录的形式解决复杂的身份管理问题。强调了身份认证、授权和审计的关系，以及访问控制模型和基本原理。接着介绍了常见的访问控制机制包括DAC、role-BAC、rule-BAC、MAC，并解释了它们的特点和适用场景。最后，提到了威胁评估的步骤，包括识别数据、识别攻击和识别漏洞，以帮助读者了解如何评估安全威胁并推动安全方案的落地。整体而言，本文内容涵盖了广泛的安全技术知识，适合读者快速了解数据保护方案的基本概念和原理。文章内容深入浅出，适合技术人员快速获取相关知识。
《安全攻防技能 30 讲》，新⼈⾸单¥59
全部留言(28)
- 最新
- 精选
rock_MAC那的机密性不能低读、高写；完整性不能高读、低写，没太懂作者回复: 就是机密用户不能往公开数据库中写数据，公开用户不能从机密数据库中读数据，相当于掐断了数据从机密流向公开的方式，从而保障机密性。完整性同理。
2020-01-06437
tt最近一直在做统一认证和单点登录的事情，还有第三方API访问认证、授权（访问权控制）的事情，自己也查了好多资料，但经过老师的梳理，所有的东西一下子结构化、调理化了好多。 在做设计方案的时候，虽然最终方案八九不离十，但始终有一种朦胧感，和领导（而不是面试官，哈哈）汇报方案的时候也总是眉毛胡子一把抓，一会儿讲数据，一会儿讲现学现卖的攻击方法，一会儿讲到SESSION、TOKEN和CORS。 有了老师给的框架，这下方便设计和汇报了。从数据和防范给领导切入，在往回说如何授权（内网采用基于角色的访问控制，公网还要加上DAC），最后落实到该选取外网基于OAuth+自有应用状态、内网基于自有token+各内部模块维护自有状态的方法。作者回复: 赞
2019-12-1816
曙光“为了保证完整性，MAC 不允许高级别的主体读取低级别的客体，不允许低级别的主体写入高级别的客体。”这个我没理解，既然是高级别的主体，为什么不能看低级别的内容呢？不能看到所有信息，还完整么？作者回复: 其实原理在于限制信息流动的方向。可以设想的场景是，如果高级别主体读取了低级别的脏数据，导致高级别执行了异常的操作或者污染了原有的数据，就是一种完整性的损失了。
2020-03-14214
律飛在设计授权机制前，需要先对需要安全保护的数据和访问控制的场景是什么。接着明确请求的发起者、请求的接收方、主体对客体进行的操作。根据实际需要，对DAC、role-BAC、rule-BAC、MAC进行组合选择使用。例如先根据role-BAC进行基于角色的访问控制，然后根据需要使具有管理员权限的DAC用户可以控制自己的文件能够被谁访问，再细化需求，判定是否需要MAC让主体和客体被划分为“秘密、私人、敏感、公开”这四个级别，作者回复: 赞～
2019-12-294
鸵鸟从MAC授权机制来看，如果需要同时保证机密性和完整性，那么不同安全级别的主体只能访问相同安全级别的客体。请问可以具体描述一下这两个点嘛？不是很理解作者回复: 是的，如果想要同时保护机密性和完整性的话，则需要禁止跨级别的数据交换。具体可以了解一下：Biba模型和Bell-LaPadula模型。
2019-12-212
honnkyou老师，【完整性不能高读、低写】这句不是很理解，能再多说两句吗？作者回复: 其实就是阻断低等级的信息流向高等级，比如高等级主体去读低等级客体，就是高读；低等级主体去写高等级客体，就是低写。
2020-05-081
bin的技术小屋老师，你们风控系统中的规则引擎大概是用什么实现的，我之前是用drools搞了一版，后来觉得觉得过于繁重，又用groovy弄了一版，把规则直接配置成动态脚本，实现热更新。还有在规则引擎的设计上除了要考虑规则的动态更新，版本，执行明细。可回溯，审计日志，这些特性，还需要考虑哪些方面呢？能否简单分享下你们的规则引擎大概得设计思路？作者回复: 要考虑的东西很多，我目前也没整理出特别体系化的设计思路。还有的特性包括：规则的复用（多个业务可能会共用某一部分规则），规则的测试（规则上线前对正确率作检测），多级规则的串联，熔断降级等。
2020-02-231
boyxie大家对于数据权限的设计有没有什么最佳实践呢，我们现在是各数据冗余用户ID和机构ID，在操作数据时加上相应的SQL过滤各个ID，不知道有没有更加解耦的方式作者回复: 最好是做到统一管理。可以是数据库层面的，也可以是应用层面的。比如数据库层面，如果是基于角色，那么可以给不同的角色定义不同的数据库视图，就可以避免获取无关的数据。应用层就是做一个统计的查询入口，进行id的过滤。
2019-12-191
Zhen条例清楚，特别是脑图把各个知识点总结的很清晰，赞! 另外，这里主要举的是网络安全的例子，其框架也可以应用到手机安全中。比如，认证阶段，不仅要通过口令、指纹、人脸等验证用户是否合法；另一方面，网络还需要验证手机是否可信是否安全；在授权或者Access control方面，SELinux/SEAndroid也是基于MAC机制的，哪些资源可被哪些进程以哪种方式访问，都预先标记设置好了；如果需要在手机上播放加密流媒体，也会有DRM方面的鉴权解密操作，保证视频被安全的访问。作者回复: 是的，安全框架对于各个场景，基本都是相通的～
2019-12-191
JianXu老师，关于审计日志，我们公司是有专门的中央日志系统的，这样各个系统把日志写入中央日志系统，查阅的人就会很方便，因为他不需要到各个系统里去看日志了。但是中央日志系统是不保证一条日志都不丢的，也就是中央日志系统的设计初衷是为了方便开发人员排查问题，而不是为了做审计。那是不是我就得做两套系统呢？感觉很浪费的样子。作者回复: 听你描述，日志的可用性能够满足开发人员排查问题，那大概率也能够满足安全人员排查问题了，两者的需求基本只是关注的字段会有些区别。安全也是需要考虑收益的，不能为了追求绝对安全浪费过多的成本。
2020-09-10
