Access Control Principles

Access Control Context

  • Authentication (認證): 驗證使用者或系統憑證的有效性
  • Authorization (授權): 授予系統實體存取資源的權利或許可
  • Audit (稽核): 獨立審查系統記錄與活動

Access Control Policies

  • Discretionary access control (DAC)
    • 基於請求者的身分 (identity)
    • rules 決定使用者的操作是否被允許
    • Discretionary (自主): 某個實體可以把自己的存取權限授予其他實體
  • Mandatory access control (MAC)
    • 基於系統實體的安全等級 (security clearances)
    • 存取由資源 security label 決定
    • mandatory (強制): 無法將權限轉移給其他實體
  • Role-based access control (RBAC)
    • 基於使用者的角色 (role)
    • 存取由 role 允許的權限決定
  • Attribute-based access control (ABAC)
    • 基於:
      • 使用者屬性 (attributes)
      • 存取的資源
      • 環境條件

Subjects, Objects, and Access Rights

Basic Elements

  • Subject: 能夠存取物件的實體
    • Owner
    • Group
    • World (All users)
  • Object: 被存取控制的資源
  • Access Rights: 描述 Subject 如何存取 Object
    • Read, Write, Execute
    • Delete
    • Create
    • Search

Discretionary Access Control

General approach

  • Access matrix
  • Subjects vs. Objects
  • Each entry: access right
  • 實務上,Access Matrix 通常是稀疏 (sparse) 的

Decomposition Method I

  • Access control lists (ACL): decomposed by columns (objects)
  • 對於每個 objects,列出哪些 user 擁有哪些權限
    • 對於沒列出的 user 套用 Default set of rights (預設權限)
  • 優點: 容易知道誰可以存取這個資源
  • 缺點: 不容易知道某個 user 有哪些權限

Decomposition Method II

  • Capability tickets: decomposed by rows (subjects)
  • 每個 capability ticket 描述: user 可存取的 object 與可執行的操作
  • 優缺點與 ACL 相反
  • 有較大的安全問題: ticket 可能散落在系統各處
    • 必須保護 ticket 的 Integrity,不可偽造 (unforgeable)

Another Approach

  • Authorization Table [SAND94]
  • 不是稀疏表示,並且相較 Decomposition Method 更方便
  • 容易使用 relational database 實作
  • 缺點: 空間可能較大、查詢效率較低

More Flexible Model: Protection Domains

  • 一組 objects 擁有相同的 access rights
    • access matrix 中一列為一個 protection domain
    • 每個 user 有一個 protection domain,該 user 建立的 processes 會繼承這些權限
  • Least privilege: 每個 process/user 應該只擁有完成任務所需的最小權限
    • 改進: user 產生 process 時,只給 subset 權限
    • 一種實作: OS 模式切換
      • UNIX: User mode/Kernel mode

Example: Unix File Access Control

  • UNIX 檔案使用 inode (index node) 管理
    • 多個檔名可以對應到同一個 inode
    • 與檔案為 1-1 關係
    • 儲存檔案的:
      • 屬性 (attributes)
      • 權限 (permissions)
      • 控制資訊 (control info)
    • 磁碟上有一個 inode table (inode list) 存所有檔案的 inode
    • 當檔案被打開時 inode 會被載入記憶體
  • Directories (目錄) 為一樹狀結構
    • 可能包含檔案或是子目錄
    • 本身也是一個檔案: 包含檔名 + 指向 inode 的指標

Traditional UNIX File Access Control

  • UNIX user: 有唯一的 user ID
    • 屬於一個 primary group 或 other groups
    • group 有自己的 group ID
  • 每個 file/directory 有 12 protection bits
    • 前 9 bits: read, write, execute
    • 後 3 bits: setUID, setGID, and sticky

SetUID/SetGID bits

  • Effective user ID/Effective group ID
  • 讓使用者暫時擁有 owner/group 的權限
  • 對 executable file:
    • 只在程式執行期間有效
    • 允許普通使用者執行需要高權限的操作
      • ex: ping command need access to networking privileges
  • 對 directory:
    • SetGID: 新建立的檔案會繼承該 directory 的 group
    • SetUID: 忽略
  • 可能產生安全風險

Superuser: 不受一般存取控制限制

  • 需要特別注意 setUID 至 Superuser 的程序

Sticky bit

  • Files: 執行後將內容保留在記憶體 (現已棄用)
  • Directories: 僅 owner 可以對目錄內的檔案進行 rename, move, or delete
    • 用於管理共享暫存目錄

Issues

  • 考慮以下情況:
    • File X: A, B 可讀
    • File Y: B, C 可讀
  • 則需要至少兩個 user groups
  • 如果有很多這種組合,則會需要大量的 groups
    • 造成不可擴展、難以管理

Modern UNIX Access Control

  • 被許多 UNIX 系統支援:

    • FreeBSD
    • OpenBSD
    • Linux
    • Solaris
  • Extended ACL vs. minimal ACL (traditional)

  • FreeBSD:

  • 一個檔案可以指定任意多個 user/group

    • 每個都有 3 protection bits
  • 可以不用 ACL: protected solely by traditional access control

  • 用一個額外的 protection bit: 是否使用 extended ACL

  • Extended ACLs

    • owner/other 類別維持不變
    • Group class 改為 mask 的功能: 最大權限限制
    • 可以新增額外的 named users/groups: 各有 3-bit permission field
    • 最終的 effective = named users/groups \cap Group class (mask)

Role-Based Access Control

  • 基於 user 的 roles 來決定權限
  • Many-to-many:
    • users to roles
    • roles to resources
  • 遵守 least privilege
    • 每個 role 只包含該角色需要的最小權限
    • user 被指派 role,只能執行該角色允許的操作

RBAC Reference Models

  • A family of reference models have been defined as the basis for ongoing standardization efforts [SAND96]
    • RBAC0RBAC_0: minimum functionality
    • RBAC1RBAC_1: RBAC0RBAC_0 + role hierarchies
    • RBAC2RBAC_2: RBAC0RBAC_0 + constrains
    • RBAC3RBAC_3: RBAC0RBAC_0 + RBAC1RBAC_1 + RBAC2RBAC_2

RBAC0RBAC_0: Base Model

  • User: 一個能存取系統的個體,有唯一的 user ID
  • Role: 一個具名的工作職責/權限等級
  • Permission: 對某個 object 的某種操作的授權
  • Session: mapping user 與其被指派的 roles 集合

RBAC1RBAC_1: Role Hierarchies

  • 責任較大的 role 擁有更高的存取權限
  • 較低階 role 的權限為其子集

RBAC2RBAC_2: Constraints

  • 用來讓 RBAC 符合實際組織的管理與安全政策
  • Mutually exclusive roles:
    • 一個 user 只能擁有其中一個 role
    • 某些 permission 只能屬於其中一個 role
    • 不同 role 的 permission 不能重疊
  • Cardinality:
    • 限制某個 role 最多可以有多少 user
  • Prerequisite role:
    • user 必須先有某個 role,才能被指派另一個 role

Attribute-Based Access Control

  • 定義授權時,會使用 resource 和 subject 的屬性

  • 優點: Strength flexibility and expressive power

  • 缺點: 每次存取都要評估 resource 和 subject,造成 performance impact

    • 在 Web service/cloud computing 中成本通常可以接受
  • Distinguishable

    • 對不同 attribute 組合做出不同 decision
    • 能夠實現 DAC, RMAC, and MAC concepts
    • Fine-grained access control: 可以組合任意多個屬性來定義規則

Attribute

  • Subject attributes
    • Subject 為 active entity: 會觸發資訊流或改變系統狀態
    • Attributes 描述其身分、特徵
      • ex: name, organization, job title
  • Object attributes
    • Object 為 passive entity: 儲存或接收資訊
    • Attributes 用於存取決策
      • ex: file name, file size, creator
  • Environment attributes
    • 存取發生時的情境
      • ex: current date, time, network type, etc.
    • 傳統 access control 通常忽略這類屬性

Case Study: RBAC System for a Bank

紅字整理

P2: Definition of Computer Security (RFC 4949)
Measures that implement and assure security services in a computer system, particularly those that assure access control service.

  • access control: the central element of computer security

P13: Discretionary Access Control (DAC), In practice, an access matrix is usually sparse!

  • 故有 Decomposition Method

P20: More Flexible Model: Protection Domains, Do the processes really need all the access rights?

  • 故有 Decomposition Method

P27: Traditional UNIX File Access Control, No scalability: unwieldy and difficult to manage

  • 需要大量的 groups,造成不可擴展、難以管理
  • 改用 Modern UNIX Access Control

P37: Attribute-based Access Control (ABAC)

  • Strength: flexibility and expressive power
  • Drawback: the performance impact of evaluating predicates on both resource and user properties for each access

P38: ABAC Model: Attributes

  • Subject attributes
    • A subject is an active entity that causes information to flow among objects or changes the system state
  • Object attributes
    • An object (or resource) is a passive system-related entity containing or receiving information

P45: Case Study: RABC System for a Bank, How to solve it?

  • 由 DAC 轉用 RABC