访问控制策略方案

访问控制策略方案（共8篇）

1.访问控制策略方案 篇一

其实，这些控制策略，不但对数据库服务器有效;对其他的应用服务器仍然具有参考价值。

一、给用户授予其所需要的最小权限

不要给数据库用户提供比其需要的还要多的权限。换句话说，只给用户真正需要的、为高效和简洁地完成工作所需要的权限。这个道理很容易理解。这就好像防止职业贪污一样。你若只给某个员工其完成工作所必需的费用，一分都不多给，那其从哪里贪污呢?

如从数据库服务器的角度来考虑这个问题，这就要求数据库管理员在设置用户访问权限的时候，注意如下几个方面的问题。

一是要限制数据库管理员用户的数量。在任何一个服务器中，管理员具有最高的权限。为了让数据库维持正常的运转，必须给数据库配置管理员账户。否则的话，当数据库出现故障的时候，就没有合适的用户对其进行维护了。但是，这个管理员账户的数量要严格进行限制。不能为了贪图方便，把各个用户都设置成为管理员。如笔者企业，在一台数据库服务器中运行着两个实例，但是，只有一个数据库管理员负责数据库的日常维护。所以，就只有一个管理员账户。

二是选择合适的账户连接到数据库。一般数据库的访问权限可以通过两种方式进行控制。一是通过前台应用程序。也就是说，其连接到数据库是一个统一的账户，如管理员账户;但是，在前台应用程序中设置了一些关卡，来控制用户的访问权限。这种方式虽然可以减少前台程序开发的工作量，但是，对于数据库服务器的安全是不利的，

二是在前台程序中，就直接利用员工账户的账号登陆到数据库系统。这种做法虽然可以提高数据库的安全性，但是，其前台配置的工作量会比较繁琐。而笔者往往采用折中的方法。在数据库中有两类账户，一类是管理员账户，只有前台系统管理员才可以利用这类账户登陆到数据库系统。另外一类是普通账户，其虽然可以访问数据库中的所有非系统对象，但是，他们不能够对数据库系统的运行参数进行修改。然后具体数据对象的访问，则通过前台应用程序控制。如此，前台应用程序普通员工只需要通过同一个账户连接到数据库系统。而系统管理员若需要进行系统维护，如数据库系统备份与还原，则可以通过数据库管理员账户连接到数据库系统。则即方便了前台应用程序的配置效率，又提高了数据库服务器的安全性。总之，我们的目的就是要限制以数据库管理员身份连接到数据库的用户数量。

在其他应用服务器中，也有管理员账户与普通账户之分。在权限分配的时候，也最好只给用户授予其需要的最小权限，以保障数据库服务器的安全。

二、取消默认账户不需要的权限

在建立账户的时候，服务器往往给给其一些默认的权限。如在数据库中，Public是授予每个用户的默认角色。任何用户，只要没有指定具体的角色，则其都可以授予Public组的权限。这其中，还包括执行各种SQL语句的权限。如此，用户就有可能利用这个管理漏洞，去访问那些不允许他们直接访问的包。因为这个默认权限，对于那些需要他们并且需要合适配置和使用他们的应用来说，是非常有用的，所以，系统默认情况下，并没有禁止。但是，这些包可能不适合与其他应用。故，除非绝对的需要，否则就应该从默认缺陷中删除。

也就是说，通常某个账户的默认权限，其是比较大的。如对于数据库来说，其账户的默认权限就是可以访问所有的非系统对象表。数据库设计的时候，主要是为了考虑新建用户的方便。而且，新建用户的时候，数据库确实也无法识别这个用户到底能够访问哪些用户对象。但是，对于企业应用系统来说，若给每个员工都默认具有这么大的访问权限，那则是很不安全的。

笔者的做法是，会把应用系统的默认用户权限设置为最小，有些甚至把默认用户权限全部取消掉。这就迫使服务器管理员在建立账户的时候，给账户指定管理员预先设定的角色。这就可以有效的防止管理员“偷懒”。在建立账户的时候，不指定角色。

2.访问控制策略方案 篇二

访问控制方案的安全性是本文关注的焦点。在一个典型的访问控制方案中,其主体可能是任何请求访问的主体(一般是具有一定智能性的),例如某些计算机进程、应用程序、网络服务等等;而客体则主要是指访问控制中需要被保护的资源,在不同的应用背景下可能会有不同的定义。客体的类型往往决定了访问的方式,这些访问方式包括对客体的各种操作,例如浏览Web页面,修改数据库表中的记录,使用某些网络服务等等。获得授权的主体就可以在一个合法的范围内使用计算机系统的资源,这就保证了正确合理的访问客体,同时也要考虑维护被授权主体的利益问题。可以说,访问控制是一个系统安全防御的第一道关口。

1 已有方案及其性能分析

目前已有多种多样的安全访问控制方案,常见的如:基于密钥管理、数字签名以及身份认证等技术的访问控制方案。如某种常见的典型方案是这样的:系统注册时会为每一位合法的用户分配一对ID号以及秘密口令,这对ID号及口令对该用户来说是惟一的。如果用户需要使用系统资源的话,系统就会要求该用户提交其ID号及相应的秘密口令,接着系统会到数据库中进行查询,从而决定是否允许该用户登录。该方案的好处是实施起来比较容易,然而却存在安全隐患。特别是当通信在非保密的信道上进行时,这在远程访问控制中非常常见的,就为搭线窃听者提供了可能性,一旦某些合法用户的ID号及秘密口令被攻击者窃取的话,后果不堪设想。更甚者,如果数据库中存储的的ID和口令对应表被窃取的话,那么攻击者就相当于完全控制了系统,这都是极其严重的安全隐患。为消除这种天然缺陷,一些增强型的访问控制方案被陆续提了出来。例如有的访问控制是利用某些密码函数对口令进行一个哈希变换,变换的结果也就是密文被保存在一个检验表中。如果攻击者在登录系统时进行认证的时候仅提供明文口令的话是不能通过的,这就增加了一定的安全性,不过该方案要求在认证客户端必须具有单向散列运算功能。基于这样一种思想,文献[1]给出了一种使用智能卡的访问控制方案。还有一些方案是利用复杂的密码算法来实现的,例如利用非对称密码算法的特性来设计访问控制协议,像文献[2]就基于智能密码钥匙提出了一种安全的认证方案,然而由于非对称密码算法的运算是比较复杂的,往往令人难以忍耐其漫长的认证时间。

本文探讨利用视觉密码的良好特性来构造安全的访问控制方案。

2 视觉密码简介

视觉密码[5,6]是由Naor和Shamir于1994年在欧洲密码学年会上提出来的,并给出了(k,n)门限视觉密码方案,这种方案体现了秘密共享的思想,其工作原理是:含有机密信息的图像按某种方式被分割成n张子图像,称之为影子图像。从各个影子图像中是无法读出原来的机密信息的,而如果将大于或等于k个的影子图像以某种方式进行叠加的话,那么就可以用肉眼读出其中的机密信息。当然,由于模式识别技术的进步,目前这种读取完全由机器来完成,比如条形码的识别技术目前是非常成熟的,如果将秘密信息以条形码的方式存放,那么信息的读取就完全可以自动进行。

虽然可以采用(k,n)视觉密码方案,但为了简单起见,本方案只介绍利用最简单的(2,2)门限视觉密码的方案。含有机密信息的原始图像是一幅黑白二值图像,它将被分割成两幅影子图像,分割方法按如下步骤进行操作:首先,原始图像中的任何一个像素点都被扩展成两个子像素点,选取对该像素点的两种可能分割中的一种(注意要进行等概率选取),以之作为影子图像中对应点的像素,黑白像素的不同分割方法如图1所示。不妨以第一种分割方式为例来演示一下(2,2)秘密分享的情况,图2显示了由分割再到叠合的过程。当影子图像P1和P2进行叠加以后,利用肉眼可以很容易地读取出机密信息“HL496”。这里,不妨用K=f(P)表示从图像P中读取信息K这一过程。

3 新的访问控制方案

本文提出的新的访问控制方案是基于视觉密码[3]的,方案中只用到两种密码部件即:对称密码算法和伪随机数发生器算法。方案中所用到的对称密码算法可以是任何一款经典的算法,例如AES[4]等。方案中所用到的视觉密码算法简单,且不需要任何高深的数学理论支撑,运行效率很高,安全性只取决于伪随机数的安全性。除此之外,本文提出的方案就不需要任何别的密码部件或算法了。该方案可分为注册和认证两个阶段。

3.1 离线注册阶段

这一阶段大致可分为四个步骤:

Step R1:合法用户Ui须向系统提交自己的身份信息申请注册,系统管理员进行审核;

Step R2:对于合格的申请者,由服务器Server为其随机产生一个IDi号,这个IDi号是用户在系统中的惟一标识;

Step R3:服务器将一幅完全空白的图像Φ分割成Pi1和Pi2,还要将{IDi,Pi2}写入到一个智能密码钥匙UKey中,并将其颁发给该用户Ui;

Step R4:服务器将{IDi,Pi1}一一对应存储到自己的数据库中。文献[7]给出了使用LDAP服务器来存储时会获得更好的安全性和速度性能,故建议采用之。

3.2 在线认证阶段

Step L1:当某个合法Ui需要访问资源时,认证客户端程序将要求他提供自己的UKey。认证程序根据IDi发出登录验证请求。

Step L2:Server在接到请求后要检验IDi的合法性,并对于非法的IDi予以拒绝。否则,就检索数据库从中读取出与IDi对应的Pi1,与此同时,Server还要生成随机数N及SK,SK的值很关键,要按照它的值来生成图片P。把P和Pi1叠加得到图像Pm,不妨用“+”表示这一过程,即Pm=Pi1+P。然后,将{Pm,N}发送给用户Ui。

Step L3:合法用户Ui在收到{Pm,N}后,将Pm与Pi2叠加可以得P(这一过程如下式表示,Pm+Pi2=Pi1+P+Pi2=Φ+P=P),再利用肉眼读取出P上的密钥SK,即SK=f(P)。对于N要进行加密后变成密文M再发送给Server,加密使用的对称密码算法记为En,而会话密钥就是这个SK。

Step L4:对于收到的M要进行解密处理,Server以SK为密钥,用对称密码算法En进行解密运算可得到N',将N和N'进行比较,只有在二者相等的情况下才允许Ui登录,并且在接下来的保密通信中,就以En为加密算法,以SK为会话密钥。这里,只对第一次发送过来的M作出回应,对于后来的将作出拒绝回应,这是为了有效地抵御拒绝服务攻击。图3示例了访问认证的过程。

4 新方案的安全性分析

1)假冒攻击

假设攻击的发起者A已获得了某个合法的IDi,以下分析一下其攻击过程:

a)A→Server:{IDi};b)→:{,}

b)Server→A:{Pm,N};

c)虽然A得到了Pm,但它不能生成密钥的图像P,这是因为它没有获得Pi1的另一个影子图像Pi2,所以无法得到SK,攻击不能成功。

2)中间人攻击

这种情况下,作为攻击者A,它可能就是一个合法用户,更甚者,它可能还获得了一些其他合法用户Ui的历史资料,如IDi,Pm,M等。尽管如此,攻击还是不会成功。因为每次在进行会话时,Pm都是由服务器自动新产生的,是个新鲜值,这样从旧的Pm识别出来的SK就已无效了,故使用它对新发过来的N进行加密处理,得到的值与从服务器端获得的N'不相等,从而会话中止,导致攻击失败。

3)重放攻击

重放攻击最可能在Step L3这一步发生。某个合法用户Ui在Step L3时向服务器发送的密文M有可能会被攻击者A记录下来,A重放这些数据,从而伪装成Ui试图访问服务器资源。对此,服务器似乎不能识别出来。尽管如此,可是A并未获得密钥SK,因而在接下来的保密通信中,它对于Server回应的加密信息不能够解密,所以攻击也会失败。

4)拒绝服务攻击(DOS)

在Step L4中只对第一次发送的M作出回应,对后面的请求都予以拒绝,因而DOS攻击无效。不可否认的是,在某些实际环境中,DOS攻击很可能发生在诸如http这样一些协议的握手阶段,这是由协议固有的缺陷造成的,只能通过别的方法解决,我们这里就不予考虑了。

5 结束语

本文利用视觉密码及对称密码算法建立一种安全的访问控制方案并分析了其安全性。存储影子图像的介质选取的是智能密码钥匙,它已是非常成熟的产品,安全可靠。对称密码算法目前已经有许多商业标准的算法,只要选择来用就可以了。总之,本文提出的方案成本低,容易实施。本方案中研究的是关于一台服务器的访问控制,今后可关注多服务器情况下的访问控制问题,比如多服务器情况下的授权,分布式或集中式验证等。此外,关于无线环境下的访问控制问题[8]也是个很有意思的研究方向。

参考文献

[1]张聪娥,曹守见,李立新.一种基于智能卡的口令认证方案[J].计算机工程,2004,30(7):104-105.

[2]宋海龙,冯国柱,李超,等.一种多服务器环境下基于智能密码钥匙的认证方案[J].计算机应用与软件,2008,25(3):4-5.

[3]Naor M,Shamir A.Visual cryptography[C]//Advances in Cryptology Eurocryp tp94.Berlin:Springer-Verlag,1995:1-12.

[4]Daemen J,Rijmen V.The Design of Rijndael:AES-The Advanced Encryption Standard[M].Berlin:Springer-Verlag,2002.

[5]Ateniese G,Blundo C,Santis A D and Stinson D.Extended schemes for visual cryptography[J].Theoretical Computer Science,1995,2(50):1325-1328.

[6]冯国柱,李超,吴翊.基于视觉密码的身份认证方案[J].计算机应用,2006,26(10):2318-2320.

[7]吴洁明,周宁.基于LDAP的信息共享平台研究与实现[J].计算机应用,2008,28(4):1042-1044.

3.自主访问控制研究 篇三

关键词： 自主访问控制    实现机制    特点    局限性

1.自主访问控制的概念

自主访问控制（Discretionary Access Control，DAC）是由客体资源的属主对自己的客体资源进行管理，由属主自己决定是否将自己的客体资源访问权或部分访问权授予其他主体，这种控制方式是自主的。也就是说，在自主访问控制下，用户可以按自己的意愿，有选择地与其他用户共享他的文件。

2. DAC的实现机制

在DAC中，把访问规则存储在访问控制矩阵中。访问控制矩阵是实现DAC策略的基本数据结构，矩阵的每一行代表一个主体，每一列代表一个客体，某个主体对某个客体的访问权限由矩阵中的每个元素表示。通过检查这个访问控制矩阵可以了解用户对任何客体的访问请求，如果矩阵中主体和客体的交叉点上有访问类型，那么访问就被允许，否则就被拒绝。

2.1基于行的DAC

这种机制是把每个主体对所在行上的有关客体（即非空矩阵元素所对应的那些客体）的访问控制信息以表的形式附加给主体，根据表中的内容不同又分为不同的具体实现机制。

2.1.1权限表机制

权限表中存放着主体可以访问的每个客体的权限（如读、写、执行等），主体只能按赋予的权限访问客体。程序中可以包含权限，权限也可以存储在数据文件中，为了防止权利信息被非法修改，可以采用硬件、软件和加密措施。因为允许主体把自己的权利转给其他进程，或从其他进程收回访问权，权限表机制是动态的，所以对一个程序而言，最好把该程序所需要访问的客体限制在最小范围内。

2.1.2口令机制

每个客体都有一个相应的口令。当主体对一个客体发出访问请求时，必须把该客体的口令提供给系统。口令不像权利那样是动态的，由于大多数实现自主访问控制的系统利用口令机制时仅允许把一个口令分配给每个客体或每个客体的每种访问模式。

2.1.3前缀表

前缀表中包含主体可访问的每个客体的名字及主体对它的访问权限。当某个主体要访问某个客体时，访问控制机制将检查该主体的前缀中是否具有它所请求的访问权。前缀表机制的实现存在以下困难：主体的前缀表可能很大，增加了系统管理的困难;只能由系统管理员进行修改，管理复杂;撤销与删除困难，系统难以决定谁对某一客体具有访问权。

2.2基于列的DAC

所谓基于列的自主访问控制是指把每个客体被所在列上的有关主体访问的控制信息以表的形式附加给该客体，然后依次进行访问控制。它有两种实现形式：保护位方式和访问控制表（ACL）方式。

2.2.1保护位机制

保护位对所有主体、主体组及该客体的拥有者指定了一个访问权限的集合，UNIX采用了这种机制。在保护位中包含主体组的名字和拥有者的名字。

2.2.2访问控制表（ACL）机制

任何一个特定的主体是否可对某一个客体进行访问都可以由访问控制表决定。它表示访问控制矩阵的方法是把一个主体明细表附加在客体上。对该客体的访问权和主体的身份都存在于该表中的每一项。目前，访问控制表（ACL）机制是实现自主访问控制策略的最好方法。

3.DAC的特点

自主访问控制是访问控制中最常见的一种方法，允许资源的所有者自主地在系统中决定可存取其资源客体的主体，即主体有自主的决定权，一个主体可以有选择地与其他主体共享资源，故此模型灵活性很高。但是由于这种自主性，自主访问控制是一种比较宽松的访问控制方式，一个主体的访问权限具有传递性。在自主访问控制中，信息总是可以从一个主体流向另一个主体，即使对于高机密的信息也是如此，因此自主访问控制的安全级别较低。另外，由于同一个用户对不同的客体资源有不同的存取权限，不同的用户对同一客体资源有不同的存取权限，用户、权限、客体资源之间的授权管理非常复杂。

4.DAC的局限性

自主访问控制将赋予或取消访问权限的一部分权利留给用户个人，系统管理者难以确定哪些用户对客体资源拥有访问权限，这样不利于全局访问控制的统一。

在许多系统关系中，用户对它所能访问的客体资源并不具有所有权，系统本身才是系统中资源的真正所有者。

在系统中，一般都希望实现访问控制与授权机制的结果与系统内部的规章制度一致，并且由管理部门统一实施访问控制，不允许用户自主地处理，显然自主访问控制已不能适应这些需求。

参考文献：

[1]张鹏.浅谈计算机访问控制技术[J].科技信息（学术版），2008.

[2]范九伦，等.访问控制技术研究进展[J].小型微型计算机系统，2004.

[3]窦燕.身份认证与访问控制系统的研究与实现[D].北京大学，2004.

[4]李晓林.信息系统中基于角色的访问控制[J].微机发展，2004.

4.网络访问控制实施攻略 篇四

对网络访问控制的政策执行与公司的业务流程密切相关。比如说一些餐馆的无线网络就是最简单的网络访问控制体系，顾客在接入网络之前就必须接受相关的协议。这只是网络访问控制最简单的例子，这些餐馆提供最简单的增值服务――上网。然而对其他环境如医院，这样的协议就过于简单了。

要为你的网络选择正确的网络访问控制类型，要知道两个前提条件。第一，要清楚网络访问控制所提供的服务，怎样提供这些服务，以及如何把这些服务纳入网络。第二点就是要有明确的、可执行的安全访问策略。网络访问控制不是创造策略，而是执行策略。没有这两点，公司网络安全问题仍旧会被认为仅仅是IT部门的职责（而这永远不是一件好事）。

对接入是开还是关？

在网络访问授权之前的有限接入，通常被称做“锁住状态”。它并不是说所有的关口都被阻止了，例如它允许你下载新的杀毒软件以升级。所以，在计划引进网络访问控制设置前，要理解并匹配准入的锁机方法。

早期的共享网络采用人为的方法，通过接入的路线和关口来限制共享，其中包括起始和终端IP地址、TCP协议、用户数据端口、IP端口以及MAC地址等。从网络建设的角度说，这需要一整套执行方法，网络访问控制方法将会自动完成一系列准入程序，

另一种方法则是以分配实际LAN/VLAN来分离整个网络中被锁定的电脑，相对简单的就是用DHCP（即动态主机配置协议）来分配。这种方法不仅可以限制性设置机器到3 VLAN中，还能设置其他客户的信息如DNS。例如，所有网页都可以通过网络服务器的一个“接受”按钮全部放行。

在一些更为高级的开关设置中，网络访问控制系统可以同那些开关一起动态控制VLAN。默认条件下，所有受网络访问控制的网站端口都自动锁住，存在有限的接入权限。只有当系统检测到机器符合网络访问控制要求的时候，才会传输指令给这些端口解除锁定。网络访问控制设备安装在一个开关点（类似SPAN端口），向ARP传输信号要求通过网关。网络访问控制把MAC地址注入用户的ARP注册表作为网关，因此会强制客户把所有非本地通信传输给网络访问控制。一旦机器通过网络访问控制的参数，就会被允许通过正确的网关。

每种方法的保护都不一样。在DHCP方法中，明智的用户都会被分配一个有效的静态IP地址，也顺带通过VLAN验证。如果知道网关的正确MAC地址，就可以通过人工创建通过网关的ARP迂回摆脱ARP中毒。不过，大部分网络访问控制系统都有针对这些行为的专门措施。

接入网络的间隔距离也应该重点考虑。与端口控制的网络访问控制方法不同，在线网络访问控制对公司广域网线路和网络严格控制，但是相同方向通关则不受限制。简单说，如果A和B都在网络访问控制网关的同侧，它们就可以互相进入。

评估终端的安全

验证用户ID是网络访问控制系统中很严格的步骤。最简单的例子，就像在咖啡馆无线上网，只当用户遵守相关协时，才能被授权上网。

5.防火墙访问控制规则配置--教案 篇五

访问规则描述了网络卫士防火墙允许或禁止匹配访问控制规则的报文通过。防火墙接收到报文后，将顺序匹配访问规则表中所设定规则。一旦寻找到匹配的规则，则按照该策略所规定的操作（允许或丢弃）处理该报文，不再进行区域缺省属性的检查。如果不存在可匹配的访问策略，网络卫士防火墙将根据目的接口所在区域的缺省属性（允许访问或禁止访问），处理该报文。在进行访问控制规则查询之前，网络卫士防火墙将首先查询数据包是否符合目的地址转换规则。如果符合目的地址转换规则，网络卫士防火墙将把接收的报文的目的IP 地址转换为预先设置的IP 地址（一般为真实IP）。因此在进行访问规则设置时，系统一般采用的是真实的源和目的地址（转换后目的地址）来设置访问规则；同时，系统也支持按照转换前的目的地址设置访问规则，此时，报文将按照转换前的目的地址匹配访问控制规则。

根据源、目的配置访问控制规则

基本需求

系统可以从区域、VLAN、地址、用户、连接、时间等多个层面对数据报文进行判别和匹配，访问控制规则的源和目的既可以是已经定义好的VLAN 或区域，也可以细化到一个或多个地址资源以及用户组资源。与包过滤策略相同，访问控制规则也是顺序匹配的，系统首先检查是否与包过滤策略匹配，如果匹配到包过滤策略后将停止访问控制规则检查。但与包过滤策略不同的是访问控制规则没有默认规则。也就是说，如果没有在访问控制规则列表的末尾添加一条全部拒绝的规则的话，系统将根据目的接口所在区域的缺省属性（允许访问或禁止访问）处理该报文。

案例：某企业的网络结构示意图如下图所示，网络卫士防火墙工作在混合模式。Eth0 口属于内网区域（area_eth0），为交换trunk 接口，同时属于VLAN.0001 和VLAN.0002，vlan.0001 IP 地址为192.168.1.1，连接研发部门文档组所在的内网（192.168.1.0/24）；vlan.0002 IP 地址为192.168.2.1，连接研发部门项目组所在的内网（192.168.2.0/24）。

图 25 根据源、目的进行访问控制示意图

Eth1 口IP 地址为192.168.100.140，属于外网area_eth1 区域，公司通过与防火墙Eth1口相连的路由器连接外网。Eth2 口属于area_eth2 区域，为路由接口，其IP 地址为172.16.1.1，为信息管理部所在区域，有多台服务器，其中Web 服务器的IP 地址：172.16.1.3。

用户要求如下：

内网文档组的机器可以上网，允许项目组领导上网，禁止项目组普通员工上网。

外网和area_eth2 区域的机器不能访问研发部门内网；

内外网用户均可以访问area_eth2 区域的WEB 服务器。

配置要点

设置区域对象的缺省访问权限：area_eth0、area_eth2 为禁止访问，area_eth1 为允许访问。

定义源地址转换规则，保证内网用户能够访问外网；定义目的地址转换规则，使得外网用户可以访问area_eth2 区域的WEB 服务器。

定义访问控制规则，禁止项目组除领导外的普通员工上网，允许内网和外网用户访问area_eth2 区域的WEB 服务器。

WebUI 配置步骤

1）设定物理接口eth1 和eth2 的IP 地址。

选择 网络管理 > 接口，激活“物理接口”页签，然后点击Eth1、Eth2 端口后的“设 置”字段图标，添加接口的IP 地址。如下图所示。

2）添加VLAN 虚接口，设定VLAN 的IP 地址，再选择相应的物理接口加入到已添 加的VLAN 中。

a）选择 网络管理 > 二层网络，激活“VLAN”页签，然后点击“添加/删除VLAN 范围”，如下图所示。

b）设定VLAN 虚接口的IP 地址。

点击VLAN 虚接口的“修改”字段图标，在弹出界面中设置VLAN.0001 的IP 为：

192.168.1.1，掩码为：255.255.255.0；VLAN.0002 的IP 为：192.168.2.1，掩码为：255.255.255.0。如下图所示。

c）设定VLAN 和物理接口的关系。

选择 网络管理 > 接口，激活“物理接口”页签，然后点击eth0 接口后的“设置” 字段图标，设置接口信息，如下图所示。3）定义主机、子网地址对象。

a）选择 资源管理 > 地址，选择“主机”页签，定义主机地址资源。定义WEB 服 务器主机名称设为172.16.1.3，IP 为172.16.1.3；定义虚拟WEB 服务器（即WEB 服务器 的在外网区域的虚拟IP 地址）主机名称设为192.168.100.143, IP 为192.168.100.143；定义 接口主机地址资源192.168.100.140（也可以是其他字符串），主机名称设为192.168.100.140, IP 为192.168.100.140；定义文档服务器，主机名称设为doc_server, IP 为10.10.10.3。定义 完成后的界面如下图所示：

b）选择 资源管理 > 地址，选择“子网”页签，点击“添加”定义子网地址资源。资源名称rd_group，以及网络地址192.168.2.0、子网掩码255.255.255.0 以及排除领导地 址:10.10.11.2 和10.10.11.3。

4）定义区域资源的访问权限（整个区域是否允许访问）。

选择 资源管理 > 区域，设定外网区域area_eth1 的缺省属性为“允许”访问，内网 区域area_eth0 和area_eth2 的缺省属性为“禁止”访问。以area_eth1 为例，设置界面如 下图所示。

设置完成后的界面如下图所示。5）选择 防火墙 > 地址转换，定义地址转换规则。a）定义源地址转换规则，使得内网用户能够访问外网: 选择“源转换”。

① 选择“源”页签，参数设置如下图所示。不设置参数，表示不对报文的源进行限 制。

② 选择“目的”页签，参数设置如下图所示。

③ 选择“服务”页签，参数设置如下图所示。

转换源地址对象为“192.168.100.140”。设置完成后的规则如下图所示。

b)定义目的地址转换规则，使得内网文档组以及外网用户都可以访问area_eth2 区域 的 WEB 服务器。选择“目的转换”

① 选择“源”页签，设置参数如下图所示。不设置参数，表示不对报文的源进行限 制。

② 选择“目的”页签，设置参数如下图所示。

③ 选择“服务”页签，设置参数如下图所示。“目的地址转换”为地址资源“172.16.1.3”。设置完成后的界面如下图所示。

6）选择菜单 防火墙 > 访问控制，定义访问控制规则。a）允许内网和外网用户均可以访问WEB 服务器

由于Web 服务器所在的area_eth2 区域禁止访问，所以要允许内网和外网用户均可以 访问Web 服务器，需要定义访问控制规则如下。① 选择“源”页签，参数设置如下图所示。

源VLAN 和源区域不选择，表示不对区域加以限制； ② 选择“目的”页签，参数设置如下图所示。③ 选择“服务”页签，参数设置如下图所示。

b）允许项目组领导访问外网，禁止项目组普通员工rd_group 访问外网。由于外网区域允许访问，所以需要添加禁止访问外网的规则如下： ① 选择“源”页签，参数设置如下图所示。

② 选择“目的”页签设置如下图所示。

③ 选择“服务”页签，参数设置如下图所示。

CLI 配置步骤

1）设定物理接口eth1 和eth2 的IP 地址。#network interface eth1 ip add 192.168.100.140 mask 255.255.255.0 #network interface eth2 ip add 172.16.1.1 mask 255.255.255.0 2）添加VLAN 虚接口，设定VLAN 的IP 地址，再选择相应的物理接口加入到已添 加的VLAN 中。

#network vlan add range 1,2 #network interface vlan.0001 ip add 192.168.1.1 mask 255.255.255.0 #network interface vlan.0002 ip add 192.168.2.1 mask 255.255.255.0 #network interface eth0 switchport trunk allowed-vlan 1,2 native-vlan 1 encapsulation dotlq 3）定义主机、子网地址资源。

#define host add name 172.16.1.3 ipaddr 172.16.1.3 #define host add name 192.168.100.143 ipaddr 192.168.100.143 #define host add name doc_server ipaddr 10.10.10.3 #define subnet add name rd_group ipaddr 192.168.2.0 mask 255.255.255.0 except ‘10.10.11.2 10.10.11.3’

4）设置区域资源的缺省访问权限：area_eth0、area_eth2 为禁止访问，area_eth1 为允 许访问（缺省权限，无需再设定）。

#define area add name area_eth0 access off attribute eth0（不允许访问内网）#define area add name area_eth2 access off attribute eth2（不允许访问内网）5）定义地址转换规则。

定义源地址转换规则，使得内网用户能够访问外网。

#nat policy add dstarea area_eth1 trans_src 192.168.100.140 定义目的地址转换规则，使得内网文档组以及外网用户都可以访问area_eth2 区域的 WEB 服务器。

#nat policy add orig_dst 192.168.100.143 orig_service HTTP trans_dst 172.16.1.3 6）定义访问控制规则。

允许内网和外网用户均可以访问WEB 服务器

#firewall policy add action accept dstarea area_eth2 dst 172.16.1.3 service HTTP 允许项目组领导访问外网，禁止项目组普通员工访问外网

#firewall policy add action deny srcarea area_eth0 srcvlan vlan.0002 src rd_group dstarea area_eth0 service HTTP 注意事项

1）目的地址需要选择WEB 服务器的真实IP 地址，因为防火墙要先对数据包进行目 的地址转换处理，当内网用户利用http://192.168.100.143 访问SSN 区域的Web 服务器时，由于符合NAT 目的地址转换规则，所以数据包的目的地址将被转换为172.16.1.3。然后才 进行访问规则查询，此时只有设定为WEB 服务器的真实IP 地址才能达到内网用户访问 SSN 区域WEB 服务器的目的。网络卫士系列防火墙处理数据包的流程请参考用户手册相 关章节。

2）定义目的地址转换规则时，不能选择目的区域与目的VLAN。

根据源端口配置访问控制规则

基本需求

案例：某银行系统应用软件使用特定的端口进行业务主机与服务器间的数据通信，为 了保证数据及设备的安全，禁止其他对于业务主机和服务器的访问。网络结构示意图如下所示。

图 26 根据源端口进行访问控制示意图

业务主机可以使用特殊端口访问服务器，不能使用其他端口。业务主机区域和服务器 区域禁止其他类型的访问。

配置要点

定义区域：area_eth1、area_eth2。

定义服务端口：FS_port

设置访问控制规则

WebUI 配置步骤

1）定义区域area_eth1 为禁止访问，并与属性eth1 绑定。选择 资源管理 > 区域，点击“添加”，如下图所示。

2）定义区域area_eth2 为禁止访问，并与属性eth2 绑定。

具体操作与area_eth1 相似，请参考area_eth1 的定义过程完成。3）定义服务端口

由于系统使用的通信端口是：4500，不是通常使用的协议端口，在设置规则前需要自 定义端口。

选择 资源管理 > 服务，激活“自定义服务”页签，进入自定义服务页面。点击右 侧“添加”，如下图所示。

选择类型：TCP，设置名称：FS_port，服务器实际使用的端口：4500。完成后点击“确 定”按钮。

4）定义访问控制规则

该规则为来自area_eth1 区域使用源端口为4500 的数据包允许通过防火墙访问 area_eth2 区域。

a）选择“源”页签，参数设置如下。

b）选择“目的”页签，参数设置如下图所示。

c）选择“服务”页签，参数设置如下图所示。

d）选择“选项”页签设置参数如下。由于所使用的软件系统所建立的连接需要长时期保持，在“连接选项”中选择“长连 接”，根据需要选择“日志记录”。点击“确定”完成ACL 规则设置。

CLI 配置步骤

1）定义区域：area_eth1、area_eth2 #define area add name area_eth1 access off attribute eth1 #define area add name area_eth2 access off attribute eth2 2）定义服务端口：FS_port #define service add name FS_port protocol 6 port 4500 3）设置访问控制规则

#firewall policy add action accept srcarea area_eth1 dstarea area_eth2 sport FS_port permanent yes log on enable yes

注意事项

由于环境所限此案例未能进行实际测试，仅供参考使用。

根据特定服务配置访问控制规则

基本需求

在进行访问控制规则的设置时，可以对用户所能访问的服务进行控制，系统预定义了

可控制的常见服务，可以实现二到七层的访问控制，用户也可以自定义服务进行访问控制。案例：某企业网络被防火墙化分为三个区域area_eth0、area_eth1 和area_eth2，三个

区域分别与接口Eth0、Eth1 和Eth2 绑定，area_eth0 连接外网，允许用户访问，area_eth1 和area_eth2 区域禁止用户访问。服务器位于area_eth1，IP 地址为192.168.100.140，内网 位于area_eth2，网络地址为192.168.101.0。企业的网络结构如下图所示。

要求：

允许内网用户访问服务器的TELNET、SSH、FTP 和Web_port 服务，其中Web_port 服务为自定义服务，端口号为8080；但不能访问Eth1 口的其他服务器和其他服务。不允许外网用户访问Eth1 口服务器的TELNET 和SSH 服务。图 27 根据服务设置访问控制规则示意图

配置要点

定义区域和地址资源

定义服务资源

定义服务组资源 设置访问控制规则

WebUI 配置步骤

1）定义区域和地址资源

a）定义区域资源area_eth0、area_eth1 和area_eth2，分别与Eth0、Eth1 和Eth2 绑定。区域权限均为“允许”。

选择 资源管理 > 区域，点击“添加”添加区域资源，界面如下图。① 添加区域area_eth0。② 添加区域area_eth1。③ 添加区域area_eth2。

服务热线：8008105119 183 设置完成后界面如下图所示。b）定义IP 地址资源

选择 资源管理 > 地址，选择“主机”页签，点击“添加”，如下图所示。c)定义子网资源

选择 资源管理 > 地址，选择“子网”页签，点击“添加”，如下图所示。

2）设置自定义服务

选择 资源管理 > 服务，激活“自定义服务”页签，配置自定义服务“Web_port” 如下图所示。

3）设置服务组资源

选择 资源管理 > 服务，激活“服务组”页签，配置服务组“内网访问服务”如下 图所示。

本例中服务组名称为“内网访问服务”，包括“Web_port、SSH、TELNET、FTP”。4)设置访问控制规则。由于服务器所在区域area_eth1 禁止访问，所以只要定义允许 访问的规则即可。

a）设置允许内网area_eth2 的网段为192.168.101.0/24 的用户访问area_eth1 的服务器（192.168.100.140）SSH、TELNET、FTP 以及8080 端口服务的访问控制规则 选择 防火墙 > 访问控制，点击“添加”按钮，设置访问控制规则。① 选择“源”页签，参数设置如下图所示。

② 选择“目的”页签，参数设置如下图所示。

服务热线：8008105119 187 ③ 选择“服务”页签，参数设置如下图所示。

服务热线：8008105119 188 设置完成的ACL 规则如下图所示。

b）设置仅允许外网区域（area_eth0）的用户访问服务器的8080 端口的服务访问控制 规则。

选择 防火墙 > 访问控制，点击“添加”按钮，设置访问控制规则。① 选择“源”页签，参数设置如下图所示。

服务热线：8008105119 189 ② 选择“目的”页签，参数设置如下图。

服务热线：8008105119 190 ③ 选择“服务”页签，参数设置如下图。

服务热线：8008105119 191 设置完成后的ACL 规则如下图所示。

CLI 配置步骤

1）定义区域资源

#define area add name area_eth0 access on attribute eth0 #define area add name area_eth1 access on attribute eth1 #define area add name area_eth2 access on attribute eth2 2）定义主机和子网地址资源

#define host add name 192.168.100.140 ipaddr 192.168.100.140 #define host subnet add name 内网 ipaddr 192.168.101.0 mask 255.255.255.0 3）设置自定义服务，服务名为Web_port，端口号为8080。#difine service add name Web_port protocol tcp port 8080 4）设置服务组资源，组名称为“内网访问服务”，包括Web_port、FTP、TELNET 和SSH 服务。

#difine group_service add name 内网访问服务 member Web_port,FTP,TELNET,SSH 5）设置访问控制规则

a）区域“area_eth2”的子网对象“内网”（192.168.101.0/24）允许访问区域“area_eth1” 的服务器的Web_port、FTP、TELNET 和SSH 服务(有自定义服务组“内网访问服务”绑 定)，服务器的IP 地址为192.168.100.140。

#firewall policy add action accept srcarea area_eth2 dstarea area_eth1 src 内网dst 192.168.100.140 service 内网访问服务 enable yes

服务热线：8008105119 192 b）设置仅允许外网用户访问服务器192.168.100.140 的8080 端口的服务访问控制规 则。

#firewall policy add action accept srcarea area_eth0 dstarea area_eth1 dst 192.168.100.140 service Web_port enable yes 注意事项

如果只允许开放某些服务，其他服务均被禁止，可以设置目的区域的默认访问权限为 “禁止”，系统在匹配完访问控制规则后将自动匹配区域的默认访问权限。

根据转换前目的地址配置访问控制规则

基本需求

背景：某企业的WEB 服务器（IP：192.168.83.56）通过防火墙将其IP 地址MAP 为

202.45.56.5 对外提供WEB 服务。WEB 服务器连在防火墙的Eth1 口（IP：192.168.83.2），且防火墙通过Eth0 口（IP：202.45.56.3）与Internet 相连，如下图所示。

图 28 根据转换前目的进行访问控制示意图

需求：为了保护企业网络的安全，网关Eth1 接口所属的区域area_eth1 设置为禁止访 问，要求Internet 用户只可访问企业WEB 服务器的HTTP 服务，要求用WEB 服务器的 MAP 地址202.45.56.5 作访问控制。

服务热线：8008105119 193 配置要点

定义主机地址资源

定义地址转换策略

定义访问控制规则

WebUI 配置步骤

1）将防火墙的Eth1 口所属区域的默认访问权限设置为“禁止”。选择 资源管理 > 区域，点击“添加”，如下图。

2）定义WEB 服务器主机地址资源R-WebServer 和虚拟主机对象V-WebServer。选择 资源管理 > 地址，激活“主机”页签，定义主机地址资源R-WebServer 和 V-WebServer。

定义R-WebServer 主机地址资源图。

服务热线：8008105119 194 定义V-WebServer 主机地址资源图。3）定义地址转换规则。

选择 防火墙 > 地址转换，并在右侧界面中点击“添加”定义目的地址转换规则。选择“目的转换”。

a）选择“源”页签，设置参数如下图。

服务热线：8008105119 195 b）选择“目的”页签，参数设置如下。

服务热线：8008105119 196 c）选择“服务”页签，参数设置如下。设置完成后的目的NAT 规则如下图所示。4）设置访问控制规则。

选择 防火墙 > 访问控制，并在右侧界面中点击“添加”定义访问控制规则。

服务热线：8008105119 197 a）选择“源”页签，参数设置如下。b）选择“目的”页签，设置根据转换前的目的地址进行访问控制。参数设置如下。

服务热线：8008105119 198 c）选择“服务”页签，参数设置如下。

服务热线：8008105119 199 设置完成后的ACL 规则如下图所示。至此，WEBUI 方式的配置完成。

CLI 配置步骤

1）将防火墙的Eth1 口所属区域的默认访问权限设置为“禁止”。#define area add name area_eth1 access off attribute eth1 2）定义WEB 服务器主机地址资源R-WebServer 和虚拟主机地址资源V-WebServer。定义R-WebServer 主机地址资源

#define host add name R-WebServer ipaddr 192.168.83.56 mask 255.255.255.定义V-WebServer 主机地址资源

#define host add name V-WebServer ipaddr 202.45.56.5 mask 255.255.255.3）定义地址转换规则。

#nat policy add orig_src any orig_dst V-WebServer orig_service HTTP trans_dst R-WebServer enable yes 4）设置访问控制规则。

#firewall policy add src any orig_dst V-WebServer service HTTP action accept enable yes

注意事项

1）因为该案例要求internet 用户只可访问内网中WEB 服务器的HTTP 服务，因此需 要事先拒绝internet 用户的所有访问，再定义访问控制规则允许其访问HTTP 服务。2）对转换前的目的地址进行匹配时，只需在“转换前目的地址”中进行选择目的地 址，而无须在“目的地址”中再选择地址。

3）在配置过程中，请确保没有与该规则相冲突的地址转换策略和阻断策略。

根据转换后目的地址配置访问控制规则

基本需求

背景：某企业的WEB 服务器（IP：192.168.83.56）通过防火墙将其IP 地址MAP 为

202.45.56.5 对外提供WEB 服务。WEB 服务器连在防火墙的Eth1 口（IP：192.168.83.2），且防火墙通过Eth2 口（IP：202.45.56.3）与Internet 相连，如下图所示。

需求：为了保护企业网络的安全，要求Internet 用户只可访问企业WEB服务器的HTTP 服务，要求用WEB 服务器的IP 地址192.168.83.56 做访问控制。图 29 根据转换后目的进行访问控制示意图

配置要点

定义主机地址资源

定义地址转换策略

定义访问控制规则

WebUI 配置步骤

1）将防火墙的Eth1 口所属区域的默认访问权限设置为“禁止”。选择 资源管理 > 区域，点击“添加”，如下图。

2）定义WEB 服务器主机地址资源R-WebServer 和虚拟主机地址资源V-WebServer。选择 资源管理 > 地址，激活“主机”页签，在右侧界面中点击“添加”定义主机 地址资源R-WebServer 和V-WebServer。定义R-WebServer 主机地址资源。定义V-WebServer 主机地址资源。3）定义地址转换规则。

选择 防火墙 > 地址转换，并在右侧界面中点击“添加”定义目的地址转换规则。选择“目的转换”。

a）选择“源”页签，设置参数如下图。

b）选择“目的”页签，参数设置如下。

c）选择“服务”页签，参数设置如下。设置完成后的目的NAT 规则如下图所示。4）设置访问控制规则。

a）选择“源”页签，参数设置如下。

b）选择“目的”页签，设置根据NAT 转换后的目的地址（R_WebServer）进行访问 控制。参数设置如下。

c）选择“服务”页签，参数设置如下。

设置完成后的ACL 规则如下图所示。至此，WEBUI 方式的配置完成。

CLI 配置步骤

1）将防火墙的Eth1 口所属区域的默认访问权限设置为“禁止”。#define area add name area_eth1 access off attribute eth1 2）定义WEB 服务器主机对象R-WebServer 和虚拟主机对象V-WebServer。定义R-WebServer 主机地址资源

#define host add name R-WebServer ipaddr 192.168.83.56 定义V-WebServer 主机地址资源

#define host add name V-WebServer ipaddr 202.45.56.5 3）定义地址转换规则。

#nat policy add orig_src any orig_dst V-WebServer orig_service HTTP trans_dst R-WebServer enable yes 4）设置访问控制规则。

#firewall policy add src any dst R-WebServer service HTTP action accept enable yes 注意事项

1）因为该案例要求internet 用户只可访问内网中WEB 服务器的HTTP 服务，因此需 要事先拒绝internet 用户的所有访问，再定义访问控制规则允许其访问HTTP 服务。2）当TOS 设备处理经过地址转换的数据包时，匹配的是目的地址转换后的地址，故 一般不需要设置“转换前目的”中的地址。

3）在配置过程中请确保没有与该规则相冲突的地址转换策略和阻断策略。

基于认证用户的访问控制

用户认证的主要目的是为了对用户进行身份鉴别、授权以及进行细粒度的访问控制，用户认证的方式主要包括本地认证（密码和证书）和第三方认证（Radius、Tacacs、SecurID、LDAP 以及域认证等等），通过将认证用户设置为用户组，访问控制规则的源和目的即可 以是用户组对象，从而实现基于本地密码认证、OTP 认证以及第三方认证用户的细粒度 的访问控制。

基本需求

Area_eth2 区域为研发部门内网，禁止外网和其余部门访问，只允许内网area_eth1 区 域的某些用户通过TOPSEC 认证客户端访问内网主机10.10.10.22 的TELNET 服务。图 30 基于认证用户的访问控制示意图 配置要点

设置区域属性

设置NAT 地址转换规则

设置认证服务器和用户组

开放相关接口的认证服务

设置基于认证用户的访问控制规则。

设置用户认证客户端

WebUI 配置步骤

1）设置区域属性，添加主机地址资源。

a）选择 资源管理 > 区域，定义内网区域area_eth2 的缺省属性为禁止访问。外网区域area_eth1 为允许访问。

b）选择 资源管理 > 地址，激活“主机”页签，定义内网TELNET 服务器的真实IP 地址资源（10.10.10.22）。

定义虚拟IP 地址资源（192.168.83.223）。如下图所示。

2）选择 防火墙 > 地址转换，设置目的NAT 规则，使得用户能够访问内网TELNET 服务器。

选择“目的转换”。

a）选择“源”页签，设置参数如下图。

6.思科路由器反向访问控制列表配置 篇六

配置实例：禁止病毒从172.16.3.0/24这个网段传播到172.16.4.0/24这个服务器网段。

access-list 101 permit tcp 172.16.3.0 0.0.0.255 172.16.4.0 0.0.0.255 established Cisco 模拟器 定义ACL101，容许所有来自172.16.3.0网段的计算机访问172.16.4.0网段中的计算机，前提是TCP连接已经建立了的。当TCP连接没有建立的话是不容许172.16.3.0访问172.16.4.0的。

设置完毕后病毒就不会轻易的从172.16.3.0传播到172.16.4.0的服务器区了。因为病毒要想传播都是主动进行TCP连接的，由于路由器上采用反向ACL禁止了172.16.3.0网段的TCP主动连接，因此病毒无法顺利传播，

检验反向ACL是否顺利配置的一个简单方法就是拿172.16.4.0里的一台服务器PING在172.16.3.0中的计算机，如果可以PING通的话再用172.16.3.0那台计算机PING172.16.4.0的服务器，PING不通则说明ACL配置成功。

7.访问控制策略方案 篇七

近年来,云计算在计算机网络与信息技术领域的发展如火如荼,其应用前景也极其诱人。云计算以其超大规模、虚拟化、高可靠性的独特优势引发计算机网络变革,然而频繁发生的云安全问题却给云计算的前景蒙上了一层阴影。云计算中的“云”即是集结了网络中大规模计算资源、软件资源及存储资源的共享虚拟资源池,因此云计算就是共享的计算,云计算中要实现资源共享,必须解决资源的访问控制问题。对于每个用户来说,在对方身份未知的情况下要求进行协同,存在很大的风险性,因为该用户可能是一个善意的用户,也可能是一个恶意的用户。因此,安全的访问控制策略就变得格外重要。“传统的访问控制技术需要设定统一的安全管理域,是一种在管理域范围内的基于身份的授权技术。”

云计算既然是通过网络中的虚拟资源池提供服务,各资源主体往往不属于同一安全管理域,同时云计算的网络覆盖范围极广,因此云计算具有跨域性、动态性等特征。而传统的基于身份的访问控制技术显然已经无法满足云计算的安全要求。当前最有效的方法就是在传统的访问控制的基础上进行改进与拓展,进而适应云计算的安全新需求。如何将传统的访问控制技术扩展更新以适应新的安全需求,解决云计算平台下的安全问题是当前研究的一大热点,也是云计算环境下的访问控制技术的重要内容。

早期的访问控制技术不仅可以保证合法用户的正常访问,防止非授权用户的入侵,而且可以解决合法用户失误操作引起的安全问题。在云计算模式下,研究者关心的是如何通过非传统的访问控制类手段实施数据对象的访问控制,而目前云计算中的访问控制技术主要是IAM(Identity and Access Management)技术,但IAM技术并不能很理想地解决云计算中跨域访问控制与授权问题。安全问题成为跨域访问中科学研究的一个重要方向,而信任是安全问题的核心。

1996年Blaze M等人提出了“信任管理”的概念,第一次将人类社会中的信任机制应用到技术领域,为解决云计算环境中的安全问题提供了一条新思路,即在信任管理的基础上,把信任机制引入到访问控制技术中,给出信任的定义与计算方法,并将这种拓展的访问控制模型植入云计算平台进行研究。

为了解决云计算这种分布式多域环境下的信任问题,采用了信任管理的方法,可以对信任采用分层的管理模型。分析分布式多域环境下的信任模型,并对模型中的信任计算与信任更新机制进行讨论,由于信任的动态性特征,信任计算是一大难点。

本文通过分析云计算安全的特点,在信任管理与RBAC模型的基础上进行改进与拓展,将信任度的概念引入访问控制模型,提出云计算中基于信任的多域访问控制策略,并给出了信任度在本地域与跨域两种计算方法,较好地实现了云计算平台与云用户之间的信任关系的建立以及跨域访问控制和动态授权。

2 相关研究

云计算作为一种新兴的信息服务模式,尽管带来新的安全风险与挑战,但其与传统IT信息服务的安全需求并没有本质的区别,它的核心需求仍然是对数据及应用的机密性、完整性、可用性和隐私性的保护,而满足这些安全需求的关键技术是访问控制技术。文献[3]分析云计算环境中对访问控制的动态需求,将基于角色的访问控制(RBAC)模型应用到云计算环境,以适应云计算复杂的访问控制管理需要,实现访问控制的动态管理并增加其可维护性。但是RBAC模型是基于标识、封闭式的,即访问控制机制适用于集中封闭式的网络环境,而不适用于大规模、开放式的分布式网络,尤其是无法满足云计算中多域环境的安全需求。因此,如何对跨域访问控制进行授权成为云计算访问控制急需解决的问题。

另外,RBAC模型在将角色分配给用户时,只验证用户的身份真实性,而没有考虑用户的行为可信性。同时,RBAC模型采用预先分配方式为角色进行访问授权,而在用户实际使用权限的过程中并不进行监管与控制,当发现用户进行恶意操作时,系统很可能已经受到侵害。为了解决这些问题,一些学者提出将信任机制集成到传统的访问控制模型中。文献[5]针对RBAC模型的不足对其进行扩展,在Blaze提出的“信任管理”的基础上,将信任的概念引入到访问控制机制,提出了基于信任的访问控制模型TRBAC(Trust Role Based Access Control Model)。

该模型从权限对用户的具体要求出发,综合计算用户的多种信任特征,实现细粒度、灵活的授权机制,从而更为安全合理地为用户分配所需的权限。文献[6]和文献[7]也都是针对RBAC的不足的改进,提出了云计算环境下基于信任的动态RBAC模型。前者给出了信任度的详细计算过程,并根据用户的角色信息和信任度为其分配资源的访问控制权限,能够降低云计算中通信的安全隐患并提高安全性。而后者多为理论分析,没有给出详细的信任度求解方法。但是以上一些研究都没有考虑到云计算存在多个安全管理域的特点,没有给出跨域的访问控制方法。

将可信计算技术融入云计算环境,以可信赖的方式提供云服务是云安全研究领域的一大热点。Santos等人在文献[8]中提出了一种可信云计算平台TCCP,基于此平台,Iaa S服务商可以向其用户提供一个密闭的箱式执行环境,保证客户虚拟机运行的机密性。

另外,它允许用户在启动虚拟机前检验Iaa S服务商的服务是否安全。Sadeghi等人认为,可信计算技术提供了可信的软件和硬件以及证明自身行为可信的机制,可以被用来解决外包数据的机密性和完整性问题。同时设计了一种可信软件令牌,将其与一个安全功能验证模块相互绑定,以求在不泄露任何信息的前提条件下,对外包的敏感(加密)数据执行各种功能操作。以上研究都是期望通过实现云计算平台的可信来保障数据资源的安全性,但是都未考虑云用户的可信性。

云计算是一个多域的环境,一般将云计算中的安全域划分为三级,各安全域之间通常根据安全需求用防火墙进行安全隔离,确保安全域之间的数据传输符合相应的访问控制策略。但是现有的访问控制模型并不能满足跨域的访问控制。文献[10]提出一种基于信任的跨域访问控制模型,该模型能够较好地实现本地域和跨域的访问控制策略。本文针对RBAC模型进行拓展,并结合文献[10]跨域访问控制的思想,提出云计算环境下的跨域访问控制策略。

3 云计算中信任的度量

人类社会是一个复杂的系统,系统中实体之间的交互依赖于彼此之间的信任关系,因此人们提出将人类社会中的信任机制引入云计算中,作为实体间交互的决策依据。文献[11]中最早提出了信任的一般概念,信任是实体在特定环境下能够安全、可靠地完成工作的能力。文章中还给出了信任关系的相关性质,信任关系总是存在于两个实体之间,并且具有动态性、传递性、特定性、模糊性和不确定性。在此后不久,计算机网络中信任的研究被广泛应用到P2P网络、电子商务、网格计算、云计算等领域。

现实生活中的信任是一个主观的概念,取决于人的经验,而将信任应用到网络环境中却往往难以用精确的模型或算法进行描述和度量。信任是对一个实体身份和行为的可信度的评估,与该实体的可靠性、诚信和性能有关。根据以上概念可以将信任分为身份信任和行为信任。身份信任用来表明实体的身份,传统的访问控制技术中往往只考虑身份信任,如身份的验证,通过身份信任以后实体就可以访问相应的资源。而现实的网络环境中,却并不能够保证通过了身份验证的用户的行为都是合法的,因此需要将实体的行为信任也列入考虑范围本文即在行为信任的基础上实施访问控制策略。

云计算环境中信任可以理解为实体在保证安全可靠的云计算服务的能力。这种方法虽然能够清晰表达信任,却无法确定信任的程度。信任度是客观存在的,在访问控制领域,信任度可以使安全策略的定义更加清晰明确,并可针对不同的信任度制定不同的安全策略。

围绕信任度的量化表达,国内外出现一些相关研究,并提出了典型的信任表达与推理模型。比较有代表性的是Beth模型和Jφsang模型。Beth模型引入了经验的概念来描述和度量信任关系,并给出了由经验推荐所引出的信任度推导计算公式,该模型将信任分为直接信任与间接信任两种,直接信任是指实体之间通过直接交互形成的信任关系,间接信任是从未交互的两实体通过中间实体的推荐而获得的信任关系。这种信任的分类方法被后续很多模型所采用根据信任的这种分类方法,可以将信任关系的建立方式分为两种:

(1)直接建立:如果两个实体之间有交互经验,就可以通过二者的交互结果直接建立信任关系;

(2)推荐建立:如果两个实体之间未交互过,可以通过第三方的推荐建立信任关系。

本文提出的信任模型就是延用了这种分类方法。J准sang模型根据概率论的思想提出了证据空间和观念空间的概念,并以此来描述和度量信任关系,该模型没有明确区分直接信任与推荐信任,但提供了推荐算子用于信任度的推导。该模型与Beth模型一样都无法有效地消除恶意推荐的影响。

本文在Beth模型的基础上进行拓展,提出基于信任的多域访问控制模型。模型中实体可以根据自己的信任策略对直接信任和信誉分配不同的权重。比如有些实体相信自己直接交互的经验,它就赋予直接信任较大的权重,有些实体没有直接交互经验得到的信任值,它比较相信同盟节点的推荐,它就赋予信誉较大的比重。

3.1 本地域的信任关系

实体访问处于同一安全管理域中的其他实体时,不需要考虑跨域访问的问题,因此可以直接将信任度引入传统的访问控制模型进行安全操作。本文在RBAC模型的基础上,建立云用户与云资源之间的信任关系,并进行本地域内信任度的评估。

假定A域是云计算环境中的某个安全管理域,域中包含多个实体n,A域中的实体之间进行交互时,计算实体之间信任度,并实施本地域的访问控制策略。本地域实体之间的信任度是由域内直接信任度和推荐信任度组成。

定义1(域内评估值):在同一域中,某个实体与另一实体完成一次交互后,另一实体对该实体的评估值,用符号E表示,评估值-1≤E≤1,负值表示不满意,将会降低信任度,正值表示满意,将会提高信任度。实体nj对ni在第k次交互完成以后给出的评估值可形式化表示为E(ni,nj)k。

定义2(服务满意度):在同一域中,某实体与另一实体完成多次交互以后,另一实体对该实体的总体服务满意度,记为S。完成k次服务以后实体nj对ni的总体满意度的计算公式如下:

定义3(直接信任度):某个实体的域内直接信任度与其域内评估值有关,域内评估值越高,实体可信度就越高,直接信任度也越高,用符号DTD表示,对于两个从未交互过的实体,DTD的值通常设为零。在A域中实体ni和nj在完成第k次交互后的直接信任度计算公式如下:

定义4(信誉):实体在域中的信誉可由实体与域内所有其他实体交互后获得的满意度求得,用Rp表示。实体ni在A域的信誉可表示为Rp(ni,A),具体计算公式如下:

定义5(域内信任度):一个实体的域内信任度是指该实体在域内的可信程度,由域内直接信任度和信誉两部分组成,用符号TD表示。A域中的第i个实体ni的信任度可形式化表示为TD(ni,A),计算公式如下:

其中,α,β,γ>0这些权重参数的值与本地域的安全策略有关,存储在本地域认证授权中心。

3.2 跨域的信任关系

不同安全管理域之间的信任度的评估与单个域中的评估方法不同,跨域之间的信任度的影响因素涉及单个实体的信任度和每个实体的行为。同时,传统的RBAC模型在跨域访问控制中不再适用,如果期望将RBAC模型应用到云计算这种多域环境中,需要进行角色的关联与转换,关于跨域角色转换问题后文会有相关介绍。

假设A、B表示云计算环境中两个不同的安全管理域,mi是B域中的实体。A域中的实体与B域中实体进行交互时,需要计算两个实体之间信任度,并实施跨域的访问控制策略。

定义6(域间直接信任度):两个域的直接信任度与域中实体对另一域的直接信任度有关。DTD(A,B)用于计算B域对A域之间的直接信任度,随着时间的改变结果会不断更新变化,计算公式如下:

定义7(域间信誉):实体mi在域A中的信誉用Rpa(mi,A)表示,则B域对A域的域间信誉为Rp(A,B),计算公式如下:

式中引入一个权值因子θj,与B域中的某个实体mj在该域中的直接信任度相对。

定义8(域间信任度):B域对A域的域间综合信任度表示为TD(A,B),由域间直接信任度和信誉两部分组成,二者由安全管理中心被分配不同的权值。

4 基于信任的多域访问控制策略

通过用户行为分析建立起用户与云计算平台之间的相互信任关系,根据信任模型计算出的信任度,结合基于角色的访问控制技术,实施云计算环境下的动态访问控制。本文针对云计算环境存在多个安全管理域的特点,将信任度引入访问控制模型中,构建云计算环境下基于信任的多域访问控制模型。基于信任的多域访问控制与传统的访问控制机制的主要区别在于用户在本地域和跨域进行访问时,采用两种访问控制策略。在基于信任的多域访问控制模型中,用户在登录时,首先要对用户的身份进行验证,对于身份可信的用户,根据其身份决定是否进行授权。同时,该模型中的用户行为信任级别反应了用户行为的可信度,使授权不再是单纯基于身份信任的静态机制,而是基于身份信任和行为信任相结合的动态机制。因此,该模型实现了用户身份信任和行为信任的结合。基于信任的多域访问控制总体框架如图1所示。

云用户首先通过角色管理中心获取相应的角色,然后与认证授权中心交互,提交用户ID、密码、角色及所要访问资源的信息,申请授权访问。若用户请求访问的资源处于本地域中,则采用本地域访问控制策略,若请求访问外域资源,则采用跨域访问控制策略,进行权限分配与管理。

4.1 本地域访问控制策略

将信任度引入基于角色的访问控制的主要方法是把信任度作为云用户与云服务或云资源的基本属性。本地域中的访问控制认证、授权及信任管理由认证授权中心AAC(Authentication and Authorization Center)负责,而跨域的访问控制与信任管理则需要高级认证授权中心MAAC(Master Authentication and Authorization Center)与AAC共同完成。

在本地域中,云用户每一次请求访问云服务或云资源,认证授权中心都会查看云用户的信任度,确保云用户的信任度达到了访问的信任度阈值,才允许云用户的访问请求。本地域的访问控制结构如图2所示。

本地域访问控制过程。

(1)在基于角色的访问控制中,云用户在发起访问控制请求之前,首先要请求角色分配,从而间接地获得相应的访问控制权限,但在本模型中,用户仅仅是通过角色获得访问权限,但能否使用这些访问权限,还要通过信任管理阶段来决定。

(2)云用户向AAC发送访问控制请求,请求信息中包括用户ID、密码和访问资源或服务的ID,AAC首先根据用户的身份信息对其进行身份认证,通过认证之后,再通过信任管理根据其信任度对云用户进行相应的授权。授权的过程包括:

(1)策略库对本域内的安全策略进行初始化;

(2)策略实施端将用户的访问请求传递给策略决策端;

(3)策略决策端将访问请求传送给策略信息端;

(4)策略信息端获取网格用户的信任度及其他属性信息,返回给策略决策端;

(5)策略决策端根据获得的用户的所有信息以及当前的安全策略,做出访问控制决策,并返回给策略实施端;

(6)策略实施端将结果反馈给用户实体。

如果用户的访问请求得到许可,就会给用户发放一个证书,这样用户就获得了其角色相对应的访问权限的使用权。

(3)云用户执行其访问控制权限,访问云服务或云资源。

(4)访问结束后,用户对云服务或云资源的性能进行评价,通过信任评估代理计算出一个新的信任度,并发送给AAC。

(5)云服务或资源提供者同样也对云用户进行信任度评估,并反馈给AAC。

4.2 跨域访问控制策略

由于云用户通常需要访问处于不同安全管理域中的云服务或云资源,安全有效地跨域访问控制十分必要。云计算环境中跨域访问控制问题的研究不多,但这却是一个不容忽视的问题。传统的基于角色的访问控制适用于封闭式的网络环境,无法满足多域环境的安全需求,因此,需要进行多域中的角色关联,即将外域中的角色转换成本地域的角色。基于信任的跨域访问控制结构如图3所示。

跨域访问控制过程如下:

(1)Bob在A域中的角色由角色分配中心分配,通过角色分配,Bob获得了A域中相应的访问控制角色。Alice在B域中的角色同样也由B域中的角色分配中心分配。

(2)Bob向A域的AAC发送访问请求,AAC计算Bob的信任度,通过本地的安全策略,AAC判断Bob是否有具有访问目的域的权限。

(3)A域的AAC将访问请求发送给MAAC,MAAC查看A域与B域的信任关系,判断访问是否被允许,如果允许,AAC给Bob发放一个证书。

(4)Bob向Alice提供访问请求和安全证书及其在A域中的角色。

(5)Alice收到Bob的访问控制请求以后,首先将Bob在A域中的角色通过角色关联转换成B域可以理解的角色,查看该角色是否具有访问Alice的资源的权限,如果有,进行第6步;如果没有,直接拒绝Bob的访问控制请求。

(6)Alice将证书交给B域的AAC。

(7)B域的AAC与MAAC联系,根据A域与B域的信任度和身份映射,MAAC完成两个域之间的联系和证书的传递,然后计算Bob在域B中的信任度,将结果返回给B域的AAC。

(8)B域的AAC将Bob的安全属性与本地安全策略进行判断,将结果反馈给Alice。

(9)Alice将授权结果返回给Bob,如果请求被允许,Alice就允许Bob使用资源,如果不被运行,Alice会拒绝Bob的请求。

(1)Bob对资源服务进行评价,将结果发送给A域的AAC,AAC再发送给MAAC。

(11)Alice对用户Bob进行评价,将结果发送给B域的AAC,AAC再发送给MAAC。

(12)MAAC根据从A、B域的AAC提供的评价值,计算并更新A、B域之间的相互信任度。

4.3 域间角色转换

在云计算网络环境中,存在多个安全管理域,因此需要考虑两个安全域之间的安全互操作问题。IRBAC2000模型首次提出了跨域的访问控制,不同的安全管理域之间通过动态角色转换实现安全互操作。管理域是被单一的管理权限所管辖,由多个主机、路由器及互联网组成的一个集合体。

在本文基于信任的访问控制模型中,继续使用RBAC模型的思想,为每个云用户被分配一个角色,该角色代表了用户所能执行的权限。如果两个安全域A和B希望进行安全互操作,A和B之间就需要建立安全上下文。安全上下文是处于某种域安全策略管理之下的两个实体之间的安全性会话。为了建立安全上下文,两个域之间必须在安全策略上达成某种共识。一种最基本的方法是两个域能建立一种缺省的安全策略,以此提供基本的安全性。但这并不能满足具有高安全可靠性要求的多域的云计算环境。例如,图2中处于A域中的Bob希望同域B中的目标对象Alice建立一个安全上下文,它必须依赖底层的安全机制来建立这个安全上下文。

为了获得更高程度的灵活性,Bob和目标对象Alice都必须知道对方的身份,这种情况在单个域中很常见。但是,因为Bob和Alice在不同的域中,他们通常互不相识,不知道对方的身份。为了解决这个问题,我们提出一个策略框架来简化两个或多个域之间的安全互操作。这个策略框架通过在本地域和外域角色层次之间建立一组关联来运转。这些关联构成一个组合的角色层次,并且该角色层次仍然是偏序的。

将外域中的某个角色a转换成本域的某个角色b,使a在本地域中获得b的权限,成为a关联到b,用符号aR1|→bR0表示,或直接简化为(a,b)。R1R0表示从R1到R0的所有关联的集合,因此有。定义角色x和角色y的关系:x>y,表示在角色层次中x高于y,或者说“x是y的祖先”。

关联分为两种,一种是可传递性关联,另一种是非传递性关联。

(1)可传递性关联

(2)非传递性关联

设有关联aR1|→bR0,但不允许aR1的祖先(即级别高于aR1的角色)继承这一关联。这样的关联称为非传递性关联,记为aR1|→NTbR0或(a,b)NT∈R1R0。

角色关联就是将外域角色转换成可被本地域实体所理解的本地角色,当这些关联建立之后,所有的外域角色将动态地转换成本地角色。

在本地域和外域角色层次之间,通过使用可传递关联和非传递关联,我们可以创建一个组合偏序关系,并且定义一种安全策略。这些策略可以分成三类。

(1)缺省策略

这种策略是在外域角色集和本地域角色g0R1(Guest)(本地域的最小角色)之间建立最小数目的关联:g1R1|→g0R0,使得

(2)明确的策略

安全员明确地将每个外域角色映射到一个本地域角色。

(3)部分明确策略

一个映射,如果它不是明确策略,并且除缺省策略外还存在一个或多个关联,则称其为部分明确策略。这种策略体现了动态角色转换真正意义上的灵活性。在这种偏序层次中,没有明确关联的外域角色仍然可以通过部分明确策略具有逻辑上的关联。

图4中标号为1、2、3的关联可以说明这种策略。考察图中域D0中和D1中的角色层次H0和H1。从角色x指向角色y的箭头表示x是y的父结点,在角色层次中x高于y。尽管H0和H1的角色层次的结构很相似,但其语义不同。如果来自外域中具有“Manager”角色的客体希望和本域中的一个应用程序进行互操作,而该应用程序通常只允许本地的“Professor”角色访问,因此须将外域“Manager”角色转换成有意义的本地角色“Professor”(即标号为1的关联)。标号为2的关联是一个非传递性关联。从图3中可以看到两个域中都有“Guest”角色。如果外域角色不能被本域理解,可以定义这样一种简单策略:将所有的外域角色都当作本地“Guest”角色对待,即从Guest H1到Guest H0的关联(标号为3)。但是,既然所有的外域角色都被当作同一类角色(本地角色Guest),显然这种方案不够灵活。

策略框架通过在两个角色层次之间添加一系列关联,产生了一种组合偏序关系。通过这种机制,可以很方便地管理某个外域角色的访问级别。对每一个外域角色,以它在本地角色层次中关联所允许的最高角色为其转换角色。

实现过程:

(1)本地域安全员通过角色编辑器建立关联;

(2)策略服务器遍历所有的关联,构造一个本地域角色的所有入口点的列表;

(3)外域主体向本地域策略服务器提供它的证书;

(4)策略服务器将该主体(主体的外域角色)的入口列表添加到该外域角色的证书中,转换完成。

5 结束语

本文讨论了云计算环境中的访问控制问题,提出了基于信任的多域访问控制模型与框架,它结合传统的基于角色的访问控制机制,并分别在本地域与外域的安全互操作中进行讨论,本地域中的访问控制中涉及角色分配、信任管理及认证授权,而跨域的访问控制涉及角色转换问题,本文使用角色关联的方法将外域的角色转换成本地域的角色,同时进行信任管理与认证授权。在云计算环境中,采用基于信任的访问控制,并考虑云计算环境包含多个安全管理域的特点,能够更加直观、有效地保障云用户及云计算平台的安全。

摘要：在云计算环境中,访问控制策略是保障云用户与云资源/服务安全的有效手段。本文在分析云计算安全特点的基础上,将信任度的概念引入基于角色的访问控制策略,并结合云计算环境存在多个安全管理域的特点,给出了信任度在本地域以及跨域的计算方法,提出基于信任度的多域访问控制框架。本地域的访问控制策略在RBAC的基础上引入信任度进行实施,而跨域的访问控制会涉及到角色转换。文章在基于信任的RBAC模型中,提出一种灵活的通过角色关联和动态角色转换实现跨域访问控制的方法。

8.访问控制策略方案 篇八

关键词：网站；安全访问；数据加密；证书

中图分类号：TP393 文献标识码：A 文章编号：1009-3044（2016）18-0023-02

HTTPS加密协议是HTTP的安全版本，由ssl+http协议构建，可进行加密传输和身份认证，比http协议更加安全。HTTPS能够为站点提供至少以下2大保障。

1）确保所有经过服务器传输的数据包都是经过加密的。

2）对网站服务器真实身份进行认证，避免被假冒。

那么，站点如何实现HTTPS加密协议呢？首先您需要到合法CA机构如沃通CA申请一张SSL数字证书。对于个人站点或者不涉及敏感信息的站点，可以申请沃通免费SSL证书，对于全球性商业网站（银行、购物、支付类），建议购买高级别的EVSS证书，不仅能保证站点数据安全，还能提高站点服务商的信誉。

HTTPS实际上应用了Netscape的安全全套接字层（SSL）作为HTTP应用层的子层。（HTTPS使用端口443，而不是像HTTP那样使用端口80来和TCP/IP进行通信。）SSL使用40位关键字作为RC4流加密算法，这对于商业信息的加密是合适的。HTTPS和SSL支持使用X.509数字认证，如果需要的话用户可以确认发送者是谁。

如何在CentOS6.5中配置Apache的HTTPS服务，这将是本文要解决的重点问题，这里以自签证书（仅用于测试）为例来搭建一个基于https访问的网站。

如果CentOS已经安装了Apache Web服务器，我们需要使用OpenSSL生成自签名证书。如果尚未安装OpenSSL，它可以使用yum来安装。

1 企业背景设计

web服务器需要为客户机提供web服务，为了让客户机能够定位到自己，web服务器需要一个固定的IP地址（192.168.1.254）。

使用setup命令配置IP地址或直接修改网卡的配置文件，来配置web服务器的IP地址：#vim/etc/sysconfig/network-scripts/ifcfg-eth0 ，配置完成后，需要重启网络服务：service network restart

搭建DNS服务，在本文中的dns解析情况如下所示：

www.yhy.com 192.168.1.254

2 方案设计

2.1安装Apache，建立主页测试文件

# yum install -y httpd （安装Apache）

#echo “This is a www.yhy.com’s httpstest webpage ”>/var/www/html/index.html

2.2 设计Apache SSL支持模块

# yum install -y mod_ssl （默认yum安装httpd是没有安装该模块的，安装后自动生产/etc/httpd/conf.d/ssl.conf文件）

2.3 证书设计

使用命令产生一个自签名的证书。首先，生成2048位的加密私钥。

# openssl genrsa -out ca.key 2048

[root@300second certs]# make server.csr（建立服务器密钥）

建立服务器证书

#openssl x509 -in server.csr -out server.pem -req -signkey server.key -days 365

#chmod 400 server.*（修改权限为400，只有拥有者可读的权限）

把创建的证书文件复制到对应目录

# cp server.crt /etc/pki/tls/certs/

# cp server.key /etc/pki/tls/private/

# cp server.csr /etc/pki/tls/private/

3 方案实施

3.1设置SSL配置Apache支持https

# vim /etc/httpd/conf.d/ssl.conf（修改SSL的设置文件，制定www.abc.com站点https访问时的相关信息）

# vim /etc/httpd/conf/httpd.conf （配置网站支持https）

NameVirtualHost *：443

SSLEngine on

SSLCertificateFile /etc/pki/tls/certs/server.crt

SSLCertificateKeyFile /etc/pki/tls/private/server.key

ServerAdmin email@yhy.com

DocumentRoot /var/www/html/

ServerName www.yhy.com

3.2设置Apache在系统启动中运行

#chkconfig –-levels 235 httpd on（设置apache服务开机立即启动）

#/etc/init.d/httpd start 或service httpd start（启动服务）

3.3强制Apache Web服务器始终使用HTTPS

如果由于某种原因，公司需要站点的Web服务器仅使用HTTPS，服务器需要将所有HTTP请求（端口80）重定向到HTTPS（端口443）。

1）强制网站使用HTTPS访问，需要在虚拟主机中添加如下语句：

# vim /etc/httpd/conf/httpd.conf

ServerName www.yhy.com：80

Redirect permanent / https：//www.yhy.com

2）强制虚拟主机使用HTTPS，需要在虚拟主机中添加如下语句：

# vim /etc/httpd/conf/httpd.conf

ServerName www.yhy.com

Redirect permanent / https：//www.yhy.com/

3）重启服务#service httpd restart 或#/etc/init.d/httpd restart

总之，站点存在用户注册登录、购买支付等交互时，HTTPS访问是大家一直推崇的访问方式，可以提供服务器的安全性。另外，服务器SSL证书也可根据自己需求去选择各种不同的SSL证书。

4 方案测试

在此可以查看证书信息和自建crt信息一致，点击【是】，看到测试页面：