Chapter 0x06 访问控制

Mar 30th, 2020

Access Control and Authorization 注意：访问控制和授权有时被当作同义词

访问控制(Access Control)

访问控制包括两部分： 1. 认证Authentication: 你是否是你声称的那个人？

  • 确定是否允许访问(access)

    访问控制机制：实现依据安全策略对使用系统资源进行控制，且仅许可授权实体*用户、程序、进程或其他系统)依据该策略使用系统资源。 --RFC4949 2. 授权 Authorization: 你能做什么？

  • 对行为进行限制

  • 施加什么限制？

授权

  • 信息安全的核心

  • 对已经获得认证的用户行为进行限制

  • 和身份认证的关系

  • 身份认证：二值化 (通过/拒绝)

    • 授权： 更细粒度

    • 经典方法

  • 访问控制列表 Access Control Lists (ACLs)

  • 访问能力列表 Capabilities (C-lists)

访问控制策略

  • 自主访问控制(Discretionary Access Control– DAC*

    • 基于请求者身份和访问规则(授权)控制访问，规定访问者可以(或不可以)做什么。

    • e.g. 传统方法

  • 强制访问控制(Mandatory Access Control– MAC)

    • 通过比较具有安全许可(表明系统实体有资格访问某种资源)的安全标记(表明系统资源的敏感或关键程度)来控制访问。

    • e.g. 军事信息安全需求

  • 基于角色的访问控制(Role-based Access Control– RBAC)

    • 基于用户在系统中所具有的角色及相关访问权限规则来控制访问

  • 基于属性的访问控制(Attribute-based Access Control- ABAC)

    • 基于用户、被访问资源及当前环境条件来控制访问

自主访问控制

  • 由客体的属主对自己的客体进行管理，由属主自己决定是否将自己客体的访问权或部分访问权授予其他主体。

    • 客体：资源(文件、目录、消息、邮件、程序等)

    • 主体：用户、应用、进程等

  • 在自主访问控制下，一个用户可以自主选择哪些用户可以共享他的文件

    • 例如，Linux系统中的两种自主访问控制策略

      • 9位权限码(User-Group-Other)

      • 访问控制列表ACL(Access Control List)

自主访问控制示例 1

自主访问控制示例 2

  • Unix文件的访问控制

隐藏通道（Covert Channel）

统一身份认证 CAS

单点登录技术 SSO

  • 单点登录SSO (Single Sign ON)

    • 在多个应用系统中，只需登录一次，即可在多个应用系统之间共享登录。

  • 统一身份认证CAS（Central AuthenticationService）

    • CAS是由耶鲁大学发起的一个企业级开源项目，为Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。

    • CAS属于Apache 2.0许可证，允许代码修改，再发布（作为开源或商业软件）。

    • 国内很多高校基于CAS实现SSO机制。

CAS体系结构

  • CAS Server

    • 服务器， 需要独立部署，主要负责对用户的认证工作

    • 为用户签发两个重要的票据：登录票据（Ticket Granting Ticket，TGT）和服务票据（Service Ticket，ST）来实现认证过程

  • CAS Client

    • 客户端，CAS Client 与受保护的客户端应用部署在一起

    • 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server

    • 支持单点登录系统中的Web 应用，如校园网中的各个应用系统

  • 协议的基础思想基于 Kerberos 的票据方式。

CAS认证过程

  • CAS Client 与受保护的客户端应用部署在一起，过滤从客户端过来的每一个 Web 请求。

  • 对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含Service Ticket (ST)

    • 如果没有，则说明当前用户尚未登录，于是将请求重定向到指定的 CAS Server ，并传递 Service （即要访问的目的资源地址），以便登录成功过后转回该地址。

  • 第 3 步：用户输入认证信息Credentials

  • 如果登录成功，CAS Server 随机产生Service Ticket，并缓存以待将来验证

  • 之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie（TGC）

  • CAS Client 在拿到 Service 和新产生的 Ticket 后，在第 5，6 步中与 CAS Server 进行身份认证，以确保 Service Ticket 的合法性。

  • 在该协议中，所有与 CAS 的交互均采用 SSL 协议。

采用CAS 实现SSO

  • 当用户访问另一个应用的服务，再次被重定向到 CAS Server时

    • CAS Server 会主动获得该 TGC cookie

    • 如果该 User 持有的TGC仍有效，那么就走基础协议图的第4步，达到SSO 的效果

    • 如果 TGC 失效，用户重新认证 (走基础协议图的第3步)

OAuth

PreviousChapter 0x05 密钥管理NextAssignments

Last updated