访问控制

1. 概述

抽象地说，都是某个主体对某个客体需要实施某种操作，而系统对这种操作的限制就是权限控制

在操作系统中，对文件的访问也有访问控制。此时“主体”是系统的用户，“客体”是被访问的文件，能否访问成功，将由操作系统给文件设置的ACL(访问控制列表)决定。比如在Linux系统中，一个文件可以执行的操作分为“读”、“写”、“执行”三种，分别由r w x表示。这三种操作同时对应着三种主体:文件拥有者、文件拥有者所在的用户组、其他用户

1.1. 管理后台

在正常情况下，管理后台的页面应该只有管理员才能够访问。但这些系统未对用户访问权限进行控制，导致任意用户只要构造出了正确的URL，就能够访问到这些页面。但是把需要保护的页面“藏”起来，并不是解决问愚的办法。

2. 垂直权限管理

访问控制实际上是建立用户与权限之间的对应关系，现在应用广泛的一种方法，就是“**基于角色的访问控制(Role-Based Access Control)**”，简称RBAC

2.1. Spring Security

Spring Security中的权限管理，就是RBAC模型的一个实现。Spring Security基于MVC框架，它的前身是Acegi，是一套较为全面的Web安全解决方案。在Spring Security中提供了认证、授权等功能

Spring Security提供两种权限管理方式

  • 一种是“基于URL的访问控制”
  • 一种是“基于method的访问控制”。
    这两种访问控制都是RBAC模型的实现，换言之，在Spring Security中都是验证该用户所属的角色，以决定是否授权

3. 水平权限管理

3.1. 区别

垂直权限控制作用在两类不同权限的角色之间，例如A是普通用户，B是管理员用户，那么B就拥有更多的可访问资源，这些资源包括某个URL下的资源、系统中的某个接口调用等

水平权限控制是作用与相同的角色之间的。例如A、B都是社交网站的用户，他们对该网站上的资源拥有同样的权限，但是各自又都有一些私有数据，类似私信列表、好友列表。因为构造一个获取其他用户私有页面的URL(REST风格，很好构造)是很简单的，所以A用户可能只要改下URL中的ID等信息就能得到B用户的URL

我现在只做过 Flask Web 开发，在用户权限管理这块主要是使用 Flask-Login ，垂直权限的管理只要用@login_required装饰器就行了，或者再添加一些自定义的权限检测装饰器。关于水平权限的隔离，暂时的思路，每个用户私信的REST url中再增加不同token来分离。token的构造可以是 md5(用户名+uid)

  • Neurohazard

来伊份购物网站没有对用户进行权限控制，通过变化URL中的id参数即可查看对应id的个人姓名、地址等隐私信息。

如果在系统己经上线后再来处理数据级访问控制问题，则可能会涉及跨表、跨库查
询，对系统的改动较大，同时也可能会影响到性能。

4. Overview

4.1. Access control

  • Access control = Authentication + Authorization
  • AEF = Access control Enforcement Function (enforce AC decision);
  • ADF = Access control Decision Function (grant/deny based on AC policy);
  • ACI = Access Control Information (AC policy).
  • Target = resources (data, services, etc)

4.2. Access operations

  • for file access:
    • read, write, execute, append (does not imply read access), delete, …
  • for network access
    • grant, deny, redirect

4.3. Design principles of access control systems

  • Check every access
  • Allow least privilege
  • Verify acceptable usage
    • invalid operations should be denied

5. Discretionary Access Control(DAC)

  • 自主访问控制
  • Identity-based access control

5.1. ACL(Access Control List)

访问控制表又称存取控制串列，是使用以访问控制矩阵为基础的访问控制表，每一个（文件系统内的）对象对应一个串列主

  • Usually, if a subject is not named, s/he has no rights over file – the principle of Fail-Safe default.
  • To shorten a list, specific users can have explicit rights and all other users (defined using wildcard) can have a default set of rights.
  • 缺点
    • 不可以有效迅速地枚举一个对象的访问权限。因此，要确定一个对象的所有访问权限需要搜索整个访问控制表来找出相对应的访问权限

5.2. Capability List/ Ticket

Thus we have all access rights of one user together. These are stored in a data structure called a capability list, which lists all the access rights or capabilities that a user ha

When a process tries to gain access to an object, the operating system can check the appropriate capability list.

  • 缺点
    • If each capability list has an entry(条目) for all objects, many entries will indicate that no access is allowed. This waste of space may be eliminated by only listing those objects for which a user has some access.
    • The set of objects accessible by one user, specially privileged users, may be very large. It can be expensive to search capability lists for such users, unless we use capability-based addressing
      • 撤销很expensive
    • Must protect capability tickets against unauthorised alterations either by users or processes
      • cryptographically protected checksum
      • 或者可信第三方
  • 现实中大部分是用ACL

5.3. Procedure-oriented

Objects are encapsulated, permitting only certain specified accesses via program execution (e.g. you can only access a web server via a browser), a trusted interface.

  • performance cost

6. Mandatory Access Control(MAC)

  • 强制访问控制
  • Clearance-based access control
    • A security clearance(安全审查后允许) is a status granted to individuals allowing them access to classified information (state or organizational secrets) or to restricted areas, after completion of a thorough background check.

6.1. vs DAC

DAC does not have information flow control -> Risk of Trojan Horse (covert channel).

MAC can prevent unauthorised information leakage (ensuring confidentiality)

  • Subjects and objects are classified into different levels of trust and sensitivity:
  • Subjects are assigned clearance levels.
  • Objects are classified into categories each assigned with a classification level.
  • Only the subjects with a certain clearance level are granted with access to objects with a given security level.
    • 信息只能从保密级别低的流向高的

6.2. BLP Model

Mandatory control rules for secrecy/confidentiality

  • No read up (read down): object’s classification must be below (or equal to) subject’s clearance.
  • No write down (write up): object’s classification must be above (or equal to) subject’s clearance.
  • 比如，1，2，3，4 ， 1级为最高机密，那么2级的人，不可以读1级数据，这将破坏保密原则

6.3. Biba Model

Mandatory control rules for integrity (here security=integrity)

  • Read up: object’s classification must be above (or equal to) subject’s clearance.
  • Write down: object’s classification must be below (or equal to) subject’s clearance.
  • 比如是董事会最高决议，它并不需要保密，谁都能看，但任何人不得破坏我的完整性，不能修改我的决议

7. Role Based Access Control(RBAC)

  • 基于角色的访问控制
    • If user population is highly dynamic, managing grant and revoke operations can be time-consuming.
    • End users are often not the owners of resource objects being managed; the organisation is.
    • Control is often based on employee functions rather than data ownership.

7.1. Security principles

  • Least privilege
  • Separation of duties

7.2. Configuring

  • Determining permissions.
  • Determining functional roles based upon tasks, responsibilities, and qualifications, etc.
  • Assign users to the roles (UA)
    • 注意是role不是group，其实本质是一回事
  • Assign permissions to roles (PA)
    • A user can have many roles; a role can have many users
    • A permission can be assigned to many roles; each role can have many permissions.

7.3. role hierarchy

  • 比如细胞生物学与分子生物学同属于生物学

    Additional constraints may be applied as well, and roles can be combined in a hierarchy where higher-level roles subsume permissions owned by sub-roles

7.4. contraints(约束)

Mutually exclusive(相互排斥) roles

  • Static exclusion: the same individual can never hold both roles
  • Dynamic exclusion: the same individual can never hold both roles in the same context
    Mutually exclusive permissions
  • Static exclusion: the same role should never be assigned both permissions
  • Dynamic exclusion: the same role can never hold both permissions in the same context

7.5. Sessions

A subject may have multiple simultaneous sessions with/in different roles

8. 其他参考