码迷,mamicode.com
首页 > 数据库 > 详细

Security Access Control Strategy && Method And Technology Research - 安全访问控制策略及其方法技术研究

时间:2015-06-17 11:18:47      阅读:243      评论:0      收藏:0      [点我收藏+]

标签:

catalog

0. 引言
1. 访问控制策略
2. 访问控制方法、实现技术

 

0. 引言

访问控制是网络安全防范和客户端安全防御的主要策略,它的主要任务是保证资源不被非法使用、保证网络/客户端安全最重要的核心策略之一。访问控制包括

1. 入网访问控制
2. 网络权限控制
3. 目录级控制
4. 属性控制等多种手段

访问控制相关领域知识是CISSP的重要章节,本文将重点讨论访问控制模型、及其相关的方法和技术

0x0: 访问控制概念组成

访问控制涉及到三个基本概念

1. 主体
是一个主动的实体,它包括
    1) 用户
    2) 用户组
    3) 终端
    4) 主机
    5) 应用
主体可以访问客体

2. 客体
是一个被动的实体,对客体的访问要受控。它可以是
    1) 字节
    2) 字段
    3) 记录、
    4) 程序
    5) 文件
    6) 处理器
    7) 存贮器
    8) 网络接点等 

3. 访问授权 
指主体访问客体的允许,授权访问对每一对主体和客体来说是给定的。例如授权访问有
    1) 读写: 读写客体是直接进行的
    2) 执行: 执行是搜索文件、执行文件
对用户的访问授权是由系统的安全策略决定的  

在—个访问控制系统中,区别主体与客体很重要。首先由主体发起访问客体的操作,该操作根据系统的授权或被允许或被拒绝。另外,主体与客体的关系是相对的,当一个主体受到另一主体的访问,成为访问目标时,该主体便成为了客体

0x1: 入网访问控制

入网访问控制为网络访问提供了第一层访问控制。它控制哪些用户能够登录到服务器并获取网络资源,控制准许用户入网的时间和准许他们在哪台工作站入网。用户的入网访问控制可分为三个步骤

1. 用户名的识别与验证
//用户还可采用一次性用户口令,也可用便携式验证器(如智能卡)来验证用户的身份
2. 用户口令的识别与验证
//对网络用户的用户名和口令进行验证是防止非法访问的第一道防线。为保证口令的安全性,用户口令不能显示在显示屏上,口令长度应不少于6个字符,口令字符最好是数字、字母和其他字符的混合,用户口令必须经过加密
3. 用户账号的缺省限制检查
//网络管理员可以控制和限制普通用户的账号使用、访问网络的时间和方式,三道关卡中只要任何一关未过,该用户便不能进入该网络

0x2: 权限控制

网络的权限控制是针对网络非法操作所提出的一种安全保护措施。用户和用户组被赋予一定的权限。网络控制用户和用户组可以访问哪些目录、子目录、文件和其他资源

0x3: 目录级安全控制

网络应允许控制用户对目录、文件、设备的访问。用户在目录一级指定的权限对所有文件和子目录有效,用户还可进一步指定对目录下的子目录和文件的权限。对目录和文件的访问权限一般有八种

1. 系统管理员权限(最高root权限)
2. 读权限
3. 写权限
4. 创建权限
5. 删除权限
6. 修改权限
7. 文件查找权限
8. 访问控制权限

用户对文件或目标的有效权限取决于以下两个因素

1. 用户的受托者指派
2. 用户所在组的受托者指派、继承权限屏蔽取消的用户权限

一个网络管理员应当为用户指定适当的访问权限,这些访问权限控制着用户对服务器的访问。八种访问权限的有效组合可以让用户有效地完成工作,同时又能有效地控制用户对服务器资源的访问,从而加强了网络和服务器的安全性

0x4: 属性安全控制

网络系统管理员应给文件、目录等指定访问属性。属性安全在权限安全的基础上提供更进一步的安全性。网络上的资源都应预先标出一组安全属性。用户对网络资源的访问权限对应一张访问控制表,描述用户对网络资源的访问能力。属性设置可以覆盖已经指定的任何受托者指派和有效权限。属性往往能控制以下几个方面的权限

1. 向某个文件写数据
2. 拷贝一个文件
3. 删除目录或文件
4. 查看目录和文件
5. 执行文件
6. 隐含文件
7. 共享
8. 系统属性等

0x5: 服务器安全控制

网络允许在服务器控制台上执行一系列操作。用户使用控制台可以装载和卸载模块,可以安装和删除软件等操作。网络服务器的安全控制包括

1. 设置口令锁定服务器控制台,以防止非法用户修改、删除重要信息或破坏数据
2. 设定服务器登录时间限制、非法访问者检测和关闭的时间间隔 

Relevant Link:

http://www.baike.com/wiki/%E8%AE%BF%E9%97%AE%E6%8E%A7%E5%88%B6
http://staff.ustc.edu.cn/~sycheng/cs/lectures/chap08_Bell-LaPadula_Model.pdf

 

1. 访问控制策略

访问控制模型(Access Control Model)描述了主体访问客体的一种框架,它通过访问控制技术和安全机制来实现模型的规则和目标,主要的访问控制模型有以下几种

1. 自主访问控制(Discretionary Access Control DAC)
2. 强制访问控制(Mandatory Access Control MAC)
3. 基于角色的访问控制(Ro1e-Based Access Control RBAC)
4. Bell-Lapadula安全模型
5. Biba安全模型
//每一种模型都采用不同的方法来控制主体如何访问客体,都有其优缺点

这些模型内置在不同操作系统核心或内核,以及为操作系统提供支持的应用程序中,对于每一个访问尝试,在主体能够与客体进行通信之前,安全内核会对访问控制模型的规则进行审核,以决定是否允许该访问请求

0x1. 自主访问控制(Discretionary Access Control DAC)

是否允许访问某个资源取决于资源本身

如果用户创建了一个文件,则他是这个文件的拥有者,文件头中包含了用户的标识符,这种所有权也可以赋予一群特定的个体。使用自主型访问控制(discretionary access control dac)的系统,可以让资源的拥有者指定哪些主体可以访问该资源,是从资源自身的角度出发的,故称为"自主型",对访问的控制是由资源拥有者自主决定的
在DAC模型中,访问根据授予用户的权限来进行限制,这意味着客体(资源)的拥有者有权指定对这些客体的访问类型,如果一个系统采用了DAC模型,那么系统管理员可以让资源的拥有者控制哪些人可以访问它们的文件
DAC模型中最常见的实现方式是访问控制列表(ACL),这个列表由客体的所有者只i的那个,由操作系统强制实施
我们使用的大多数操作系统都是基于自主型访问控制模型的,都是用ACL实现DAC模型的实例
DAC可适用于目录树结构及其包含的文件,计算机领域采用的访问权限包括

1. 不能访问
2. 读(r)
3. 写(w)
4. 执行(x)
5. 删除(d)
6. 更改(c)
7. 完全控制
//在Linux、windows上的具体实现中会有微小差别

DAC系统根据主体的身份来许可或拒绝访问,身份可以为用户身份或组成员
0x2. 强制访问控制(Mandatory Access Control MAC)

在强制型访问(mandatory access control mac)模型中,用户和数据的所有者没有决定谁能访问这些文件的权利,这应该是由操作系统最后做出的决定,并且可能会覆盖用户的设置,这种模型更为结构化并更加严格,一般基于"安全标签系统"来实现,用户被赋予一个安全级别(秘密、机密、绝密等),并且数据被分成了多个类别,这种级别和分类存储在资源的安全标签中
分类标签被绑定到某个主体或客体上,当系统接到一个客体访问请求时,操作系统根据主体的安全级别和客体的安全类别来作出决策,主体如何访问数据的规则由管理层制定、配置、管理,由操作系统来进行实施,由安全技术支持
安全标签和各个客体附在一起,原则上每一个文件、目录、设备都有其自己的安全标签以及分类信息,一个用户可能具有秘密(secret)的访问级别,他要访问的数据具有绝密(top secret)的安全标签,这种情况下用户会被拒绝访问,因为它的安全级别不等于或低于客体的安全类别

任何时候,每个主体和客体都必须有一个带有属性的相关联标签,因为这是操作系统访问决定标准的一部分,每个主体和客体并不需要唯一性的标签,但它们在逻辑上必须相互关联,例如服务器上的所有主体和客体可以共享相同的秘密访问许可和分级

这种模型主要用在信息分类和机密性要求非常高的环境中,例如军队,只有一些专门开发的UNIX系统支持MAC模型,最常见的MAC系统是SELINUX

1. 敏感度标签

采用MAC模型时,每一个主体和客体必须有一个敏感性标签,也称为安全标签,他包含

1. 一个级别: 级别表示了敏感级别,级别具有一个层次结构,一个级别可能比另一个级别更受信任
    1) 在一个军事环境中,信息按安全级别可以分为绝密(top secret)、秘密(secret)、机密(confidential)、未分类(unclassified)
    2) 在一个商业机构中,信息按安全级别可以分为机密(confidential)、私有(proprietary)、公司(corporate)、敏感(sensitive)
对信息级别的定义由组织自己负责,并且只在公司内部有意义

2. 不同的类别: 类别则用于强调须知规则,类别没有层次,因为它们代表系统中不同域内的信息
标签的类别部分用来实施须知规则,一个具有绝密级别的用户并不意味着他可以访问所有绝密的信息 

技术分享

在MAC模型中,系统通过比较主体和客体的安全标签来做出访问决策(类似查表的过程),但是在DAC模型中,系统需要比较主体的安全令牌(访问权限)和资源的ACL来决定
0x3. 基于角色的访问控制(Ro1e-Based Access Control RBAC)

基于角色的访问控制(role-based access control rbac)也称作非自主型访问控制,它使用"集中管理"的控制方式来决定主体和客体如何交互,这种模型允许用户基于他所处的角色来访问资源
在UNIX/LINUX POSIX标准采用的访问控制管理以DAC模型为基础,它在角色层使用ACL指定访问控制,即DAC+RBAC组合的模式,使用更粗的角色粒度来分配客体(资源)的访问权限
在RBAC模型中,某个角色会根据该角色所执行的操作和任务来定义

角色的引入也引入了显式授权和隐式授权的不同
1. 如果权限是显式分配的,那么这种权限是分配给特定的个人的: DAC
2. 如果这些权限是分配给一个角色或用户则的,则用户能自动继承角色的属性: RBAC

RBAC模型是员工流动性较高的组织最适合的访问控制系统,或者进一步说更适合在文件经常变动的文件系统上部署DAC+RBAC模型的ACL检查

1. 核心RBAC

这个组件将整合到每一个RBAC模型中,因为它是这个模型的基础。用户、角色、许可、操作、会话应根据安全策略进行定义并相互对应

1. 用户与权限之间存在多对多n:n的关系
2. 会话是某个用户与少数几个角色之间的对应关系
3. 提供传统但稳健的基于群组的访问控制

许多用户可能属于多个组,并拥有每个组所享有的各种权限,当用户登录时(这是一个会话),该用户所分配到的各种角色和组将立即对这个用户生效,即获得这些组的权限
这种模型提供了稳健的选择,因为它在做出访问决策时能够包括其他组件,而不是仅仅根据一组证书做出决策,还可以配置RBAC包含时间、角色位置、星期等方面,这意味着不仅用户ID和证书,其他信息也可用于做出访问决策
2. 层级RBAC

这个组件允许管理员建立一个组织RBAC模型,将某个环境中的组织结构和功能描述对应起来,形成了一个层次关系

1. 角色关系定义了用户成员与权限继承,所有层级是其他角色的权限和许可的累加
2. 反映组织结构和功能描述
3. 两种类型的层级
    1) 有限层级: 只允许一个层级(角色1继承角色2的权限,没有其他角色)
    2) 普通层级: 允许多个层级(角色1同时继承角色2、角色3的许可)

层级是一种划分角色结构并反映结构的授权和责任的自然方法,橘色层级(role hierarchy)定义角色之间的继承关系,这个模型提供两种不同类型的责任分割

1. RBAC中的静态责任分割(SSD)关系: 这种责任分割通过限制组合各种权限来防止欺诈
2. RBAC中的动态责任分割(SSD)关系: 这种责任分割通过限制各种可在任何会话中激活的权限来防止欺诈

基于角色的访问控制可通过以下方法进行管理

1. 非RBAC方法: 用户直接对应用程序对应起来,不使用角色
2. 有限的RBAC方法: 用户与多个角色相互对应起来,并直接与其他类型的没有基于角色访问功能的应用对应起来
3. 混合型RBAC: 用户与多个应用程序角色对应,仅分配给这些角色选定的权限
4. 完全的RBAC方法: 用户与企业角色相互对应

0x4. Bell-Lapadula安全模型

Bell-lapadula是20世纪70年代,美国军方提出的用于解决分时系统的信息安全和保密问题,该模型主要用于防止保密信息被未授权的主体访问
使用Bell-lapadula模型的系统会对系统的用户(主体)和数据(客体)做相应的安全标记,因此这种系统又被称为多级安全系统(类似MAC模型),级别和模型用于限制主体对客体的访问操作,该模型用于加强访问控制的信息保密性
Bell-lapadula使用主体,客体,访问操作(读、写、读/写)以及安全级别这些概念,当主体和客体位于不同的安全级别时,主体对客体就存在一定的访问限制。实现该模型后,它能保证信息不被不安全的主体所访问
Bell-lapadula有三条强制的访问规则

1. 简单安全规则(simple security rule): 简单安全规则表示低安全级别的主体不能从高安全级别客体读取数据
2. 星属性安全规则(star property): 星属性安全规则表示高安全级别的主体不能对低安全级别的客体写数据
//它们都是从防止信息泄漏的角度出发的
3. 强星属性安全规则(strong star property): 强星属性安全规则表示一个主体可以对相同安全级别的客体进行读和写操作

值得注意的是,所有的MAC系统都是基于BELL-LAPADULA模型,因为它允许在代码里面整合多级安全规则,主体和客体会被设置安全级别(在MAC模型中被称为安全标签),当主体试图访问一个客体,系统比较主体和客体的安全级别,然后在模型里检查操作是否合法和安全。下图是对bell-lapadula模型的简要描述

技术分享

1. 当安全级别为Secret的主体访问安全级别为Top Secret的客体时,简单安全规则(simple security rule)生效,此时主体对客体可写不可读(no read up) 
2. 当安全级别为Secret的主体访问安全级别为Secret的客体时,强星属性安全规则(strong star property)生效,此时主体对客体可写可读 
3. 当安全级别为Secret的主体访问安全级别为Confidential的客体时,星属性安全规则( star property)生效,此时主体对客体可读不可写(no write down) 

0x5. Biba安全模型

Biba模型是在bell-lapadula模型之后开发的,它跟bell-lapadula模型很相似,被用于解决应用程序数据的完整性问题

1. Bell-lapadula使用安全级别(top secret、secret、sensitive等),这些安全级别用于保证敏感信息只被授权的个体所访问
2. Biba模型不关心信息保密性的安全级别,因此它的访问控制不是建立在安全级别上,而是建立在完整性级别上 

如果布署正确的话,Biba模型能够防止数据从低完整性级别流向高完整性级别,跟Bell-lapadula一样,Biba模型也有三条规则提供这种保护

1. 星完整性规则(*-integrity axiom): 星完整性规则表示完整性级别低的主体不能对完整性级别高的客体写数据,即破坏高等级的完整性
星完整性规则(*-integrity axiom)强调主体如何修改(写)客体

2. 简单完整性规则(simple integrity axiom): 简单完整性规则表示完整性级别高的主体不能从完整性级别低的客体读取数据
简单完整性规则(simple integrity axiom)强调主体如何从客体进行读操作

3. 恳求属性规则(invocation property): 恳求属性规则表示一个完整性级别低的主体不能从级别高的客体调用程序或服务
而恳求属性完整性规则(invocation property)则强调一个主体如何跟另外一个客体(可以是另外一个主体)进行通信并对其进行初始化,例如:一个主体可以通过它的进程发送一个请求消息调用另外一个客体的执行程序,从而完成某项任务。在Biba模型里,主体只允许去调用低完整性客体的程序或服务,反之则禁止。这就保证低完整性的主体不会去调用某个高完整性客体的清除工具清除该客体的数据
//Linux中的sudo命令就是一种恳求属性规则的应用

下图是对Biba模型的简要描述

技术分享

1. 当完整性级别为Medium Integrity的主体访问完整性级别为High Integrity的客体时,星完整性规则(*-integrity axiom)和恳求完整性规则(invocation property)生效,此时主体对客体可读不可写(no write up),也不能调用主体的任何程序和服务;
2. 当完整性级别为Medium Integrity的主体访问完整性级别为Medium Integrity的客体时,此时主体对客体可写可读 
3. 当完整性级别为Medium Integrity的主体访问完整性级别为Low Integrity的客体时,简单完整性规则(simple integrity axiom)生效,此时主体对客体可写不可读(no read down) 

Relevant Link:

http://wenda.tianya.cn/question/494ef8f320019d38
http://214994.blog.51cto.com/204994/578099

 

2. 访问控制方法、实现技术

一旦一个组织决定了采用什么样的访问控制模型,那么就需要进一步确定能够支持该模型的方法和技术,我们接下来具体讨论访问控制模型对应的实现技术
下面是三种不同的访问控制模型的主要特点

1. DAC: 数据的拥有者决定谁能访问该资源,访问控制列表用于执行安全策略
2. MAC: 操作系统通过使用安全标签来执行系统安全策略
3. RBAC: 访问决策基于主体的角色和功能的位置

0x1: 基于规则的访问控制

基于规则的访问控制使用特定的规则来规定主体与客体之间可以做什么,不可以做什么,它基于"如果X则Y"这样简单的编程规则,可以为针对资源本身提供更加细化的访问控制,下面是一个基于规则的例子

电子邮件的附件大小不得大于5MB,这一规则适用于所有用户,并不单独针对某个用户,如果将基于规则改为基于身份,则会造成很大的混乱和冗余
//基于规则的访问控制通过制定一个适用于所有用户的规则,无论它是什么身份,从而简化了规则制定

基于规则的访问控制允许开发者详细定义各种特殊情形,规定在这些情形中,主体是否能够访问客体,以及在访问得到许可后主体能够执行的操作。基于规则的访问控制典型地用在MAC系统中,作为MAC系统提供的一种复杂访问规则实施机制
同时,基于规则的访问控制也用在其他类型的系统和应用程序中,例如入侵检测、内容过滤使用"如果-则(if-then)"编程语言,将数据或某种活动与一组规则进行比较,许多路由器和防火墙使用规则决定允许或拒绝哪些类型的数据包访问网络,基于规则的访问控制是一种强制型控制,这些规则由管理员制定
0x2: 限制性的用户接口

限制性的用户接口通过不允许提供提交某些功能、信息、或访问某些系统资源的请求来限制用户的访问能力,有以下几种典型的限制性接口

1. 菜单和命令
    1) 当使用菜单和命令限制时,用户只被给与它们能够执行的命令选项
    2) 命令解释器是一个系统的虚拟环境,如果采用了限制性命令,那么命令解释器就只包含管理员希望用户能运行的命令

2. 数据库视图
3. 物理限制接口
物理性的用户接口限制可以在键盘上提供一个特殊的键或在屏幕上提供触摸按钮,ATM提款机就是这种设计思想,这种装置有一个操作系统,他能够接收所有的命令和设置,但是我们在物理上受限不能执行这些功能,我们只能按键来进行提款、查询、结算、存款操作

4. Linux namespace、cgroup隔离
5. Linux chroot隔离
6. WEB系统中根据不同用户身份显示不同的功能界面

0x3: 访问控制矩阵

访问控制矩阵是一个包含有主体和客体的表,它规定每一个主体对每一个客体所能执行的操作,矩阵是一个数据结构,它用于程序员进行表查询以供操作系统进行调用

技术分享

这种类型的访问控制一般都具有DAC模型的特征,访问权限可以直接分配给主体(访问能力)或客体(访问控制列表),LINUX POSIX ACL典型地就是这种设计思想
0x4: 访问能力表

访问能力表给出了某些特定的主体对一些确定的客体进行操作的访问权限,访问能力表和访问控制列表是完全不同的,这是因为主体被绑定在访问能力表中,而客体被绑定在访问控制表中,即它们出发点是不同的

1. 访问控制表: 从客体的角度出发
2. 访问能力表: 从主体的角度出发

技术分享

一个基于访问能力的系统就是Kerberos,在这个系统中,Kerberos先给用户提供一个票证,这个票证就是一个访问能力表,将这个票证和用户绑定在一起,上面标明了用户可以访问哪些客体以及能够访问到什么程度

1. 访问能力可以为令牌、票证、或密钥,如果主体提供一个能力组件,操作系统(或应用程序)将审查该能力组件中的访问权限,并只允许主体执行这些功能。能力组件是一种数据结构,其中包含一个唯一客体标识,以及主体对该客体的访问权限
2. 客体可以为文件、数组、内存段、或端口。每一个用户、进程和应用程序在访问能力系统中都有自己的一组能力

0x5: 访问控制列表

访问控制列表(access control list acl)用于不同的操作系统、应用程序和路由器配置中,它们是一些主体被授权访问一个特定的客体的权限列表,列表定义了授权的程度,授权可以具体到一个个体或组
访问控制列表给出了访问控制矩阵中和客体有关的内容,其中访问能力表对应的是访问控制矩阵中的行,而访问控制列表是对应的访问控制矩阵中的一列

技术分享
0x6: 基于内容的访问控制

在基于内容的访问控制中,对客体的访问主要取决于客体的内容,例如snort等NIDS都是基于内容的访问控制
0x7: 基于情形的访问控制

与基于内容的访问控制不同,基于情形的访问控制根据一组信息的情形,而不是信息本身的敏感性做出访问决定,使用基于情形的访问控制的系统先"审计情况"(常常表现为一个行为序列),再做出决定,例如基于状态的防火墙需要了解协议通信的所有步骤,了解一个会话任务的必要步骤,这就是基于情形访问控制的一个实例
通过将监控到的行为序列和预定义的规范行为序列进行比较,来判断当前会话是否处于异常状态

Relevant Link:

《CISSP认证考试指南》

 

Copyright (c) 2015 LittleHann All rights reserved

 

Security Access Control Strategy && Method And Technology Research - 安全访问控制策略及其方法技术研究

标签:

原文地址:http://www.cnblogs.com/LittleHann/p/4581326.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!