一个安全保障体系的整套解决方案

“x911tt”通过精心收集，向本站投稿了3篇一个安全保障体系的整套解决方案，下面是小编为大家整理后的一个安全保障体系的整套解决方案，如果喜欢可以分享给身边的朋友喔!

一个安全保障体系的整套解决方案

篇1：一个安全保障体系的整套解决方案

一个安全保障体系的整套解决方案

前言

随着计算机技术应用的日益普及，人们发现计算机安全成了当务之急。需要解决的问题是确保信息系统中硬件、软件及正在处理、存储、传输信息的保密性、完整性和可用性。涉及的安全性有：完整性――操作系统的正确性和可靠性、硬件和软件的逻辑完整性，防止信息被未经授权的篡改；可用性――保证信息及信息系统确实为授权使用者所用，防止由于计算机病毒或其它人为因素造成的系统拒绝服务或者为敌手所用却对授权者拒用。还有对计算机安全的威胁扩展到病毒、非法访问、脆弱口令、黑客等等。

1 目前常用的多种解决方案

（1）安全管理中心

建立一套集中管理的机制和设备，用来给各网络安全设备分发密钥，监控网络安全设备，收集网络安全设备的审计信息等；

（2）检测系统检测是利用审计跟踪数据监视入侵活动；

（3）安全的'操作系统给系统中的关键服务器提供安全运行平台；

（4）安全数据库

确保数据库的完整性、可靠性、有效性、机密性、可审计性及存取控制与用户身份识别等；

（5）容灾系统

容灾就是能够恢复数据在灾难发生前的系统状态。在相隔较远的异地，建立多套功能相同的系统，进行监视和功能切换。数据容灾是信息安全战略中非常重要的一个环节。

2 提出一整套系统安全解决方案

建立安全保障体系由安全手段、安全机制和安全环境三部分组成。系统安全手段包括系统手段和业务手段；安全机制包括系统机制、业务机制、环境机制；安全环境包括配套设备和机房环境。

3 系统安全保障建立

3.1 安全手段支撑

1）设备安全

服务器采用阵列盘或镜像盘技术；采用CLUSTER技术；采用双机或多机热备份容错系统；生产服务器和开发测试服务器分离；提供光盘备份库；保证24小时不间断运行；建立异地备用服务器。

工作站及终端具有防病毒功能；保证24小时不间断运行。

网络设备采用多传输媒介组成多路由制；结驳简单、可靠；保证24小时不间断运行。

2）支撑软件安全

操作系统：

符合C2级安全标准，提供完善的操作系统监控、报警和故障处理。

[1] [2] [3] [4]

篇2：一个安全保障体系的整套解决方案

一个安全保障体系的整套解决方案

前言

1 目前常用的多种解决方案

（1）安全管理中心

建立一套集中管理的机制和设备，用来给各网络安全设备分发密钥，监控网络安全设备，收集网络安全设备的审计信息等；

（2）检测系统检测是利用审计跟踪数据监视入侵活动；

（3）安全的操作系统给系统中的关键服务器提供安全运行平台；

（4）安全数据库

确保数据库的完整性、可靠性、有效性、机密性、可审计性及存取控制与用户身份识别等；

（5）容灾系统

2 提出一整套系统安全解决方案

3 系统安全保障建立

3.1 安全手段支撑

1）设备安全

工作站及终端具有防病毒功能；保证24小时不间断运行。

网络设备采用多传输媒介组成多路由制；结驳简单、可靠；保证24小时不间断运行。

2）支撑软件安全

操作系统：

符合C2级安全标准，提供完善的操作系统监控、报警和故障处理。

数据库系统：

符合C2级安全标准，提供完善的数据库监控、报警和故障处理。大型关系数据库有如下的安全机制以保证数据库的安全：

数据库级的安全性，对整个数据库起作用。

表级的安全性，只对相关的表起作用。

列级的安全性，只对相关的列起作用。

行级的安全性，只对相关的行起作用。

类级的安全性，只对使用的隐含的类起作用。

管理和使用用户权限的另一种方法是使用角色。在数据库环境中角色的概念相当于UNIX操作系统中的组的概念。在数据库系统中角色的目的是让DBA对数据库的权限进一步细化。

数据库系统的审计策略是数据库安全性的重要组成部分之一。大型关系数据库系统提供的审计机制符合Trusted Computer System Evaluation Criteria（CSC-STD-001-83）C2级标准及Trusted Database Interpretation（NCSC-TC-021）标准。对每一个选择出的用户的活动，大型关系数据库系统提供的审计功能将产生一条记录。这些记录将用于以下用途：

发现非法用户及可疑用户的行为并指出其执行的操作；

发现未授权的访问企图；

评价潜在的损害安全机制的因素；

假如有需要，为调查提供证据。

3）网络系统安全

支持鉴别、接入控制、数据机密等一组安全功能；与其它系统的连接必须建立防火墙隔离；提供完整的网络监控、报警和故障处理。

组建的可以是企业的内部网。同时，各个系统的主机的连接都采用了前置机通讯的方式，前置机实际上起了一定的防火墙作用，增加了非法用户企图通过某台主机攻击网内其它主机的难度。其次，企业网在与外界主机相连时，都将采用国产的`防火墙产品，将有效的防止外界非法用户对网内主机的入侵。

对于通过广域网连接上线的用户，可以通过路由器加密等手段保证数据在广域网（特别是公用数据交换网）传输时数据的保密性和完整性，但会占用一定网络带宽。如果远程用户是通过DDN专线连接，应该说数据传输过程是比较安全的。

&nbs

p; 对于局域网上的用户，最好的方法是将业务应用的子网和公网隔开，当然物理上完全断开不大可能，可以通过在总部局域网交换机上设置业务专用的虚拟子网VLAN。这样可利用现有设备，无需额外的资金投入。

4）应用系统安全

一个安全保障体系的整套解决方案符合C2级安全标准，提供完善的问权限的识别和控制功能，提供多级密码口令保护措施。

应用系统的安全性建立在数据库管理系统的安全性之上，为保证系统的安全性，系统对操作员实行严格的分级权限管理，每一个操作员均拥有各自的工号（帐号）、登录密码和权限等级。特定的权限等级只能进入特定的功能模块进行授权操作。除对系统的查询操作外，任何一个对系统的“写”操作（如录入、修改、删除资料）均将在系统中留下完整的记录，包括该“写”操作发生的日期、时间、操作员工号以及对系统进行了何种操作，以备日后追查。为了保证密码的可靠性，对于操作员的密码，用户的密码，均以密文的方式在数据库中存放，这些密码只能修改而不能够直接读取。

3.2 系统数据安全

1）数据备份与恢复

系统数据可进行联机备份；

系统数据可进行联机恢复；

被恢复的数据必须保持其完整性和一致性；

提供完整的系统数据监控、报警和故障处理。

2）数据的传送与接受

保证系统数据的传送完整；

保证系统数据的传送机密；

提供完整的系统数据传送监控和报警处理。

3.3 安全环境支撑

1）配套设备安全

配套先进的、完善的供电系统和应急报警系统。

2）机房环境安全

机房要防火、防尘、防雷、防磁；

机房温度、湿度、电压应符合计算机环境要求；

机房要进行定期维护保养。

3.4 安全机制支撑

1）系统安全机制

系统应具备访问权限的识别和控制功能，提供多级密码口令或使用硬件钥匙等选择和保护措施；

系统应能提供操作日志记录功能，以便即时掌握运行状况；

系统应具备完善的检测功能，确保系统处理的准确性。系统每个环节的检测实行闭环管理，并建立与应用系统相对独立的检测系统，校验处理准确性；

建立校验结果和安全逻辑异常情况报警系统。

2）业务安全机制

建立严格的管理制度和开发、维护、运行管理机制；

应用鉴别权限与访问控制功能，对系统管理员、数据库管理员、数据管理员、操作员必须授予各种访问权限，包括人员身份、人员的密码、所属的地理位置及指令的控制，进行权限分割、责任分割；

要保证未授权的人员不能访问应用管理系统，在应用管理系统安全性受到破坏时必须产生告警；

保证只有授权的人员或系统可以访问某种功能，获取某种数据。

3）环境安全机制

建立严格的机房安全管理制度；

及时审查日志文件；

非工作人员不准入机房；

任何人不得将有关资料泄密、任意抄录。

4 结论

通过建立技术先进、管理完善、机制健全的系统安全体系，能有效保证企业系统安全运行、保守企业和用户的秘密、维护企业的合法权益：

（1）网络不间断、畅通地运行；

（2）应用系统高效、稳定地运行；

（3）系统数据准确、完整、恢复及时；

（4）系统不受外部和内部非法侵害。

篇3：一个ASP.NET虚拟主机安全漏洞的解决方案

一个ASP.NET虚拟主机安全漏洞的解决方案

曾经很早就在网上看到一篇关于＜asp.net虚拟主机的重大隐患＞的文章，当时并不在意，做过asp虚拟主机的朋友可能都知道，即对每一个用户都设置一个独立的服务器用户和单个目录的操作权限，能够基本上解决asp的fso问题。

在网上无意中发现了一个叫做webadmin的asp.net-webshell，对自己的服务器进行测试的时候，让我大吃一惊，居然对我服务器的c盘有读取的权限。以及对整个硬盘的修改删除权限。这样的话，那么我的服务器的安全……

为了进一步证实，本人曾在国内一些著名的虚拟主机提供商上作过测试，均有和我一样的问题。

有必要先介绍一下漏洞的原因。

ASP中常用的标准组件：FileSystemObject，这个组件为 ASP 提供了强大的文件系统访问能力，可以对服务器硬盘上的任何有权限的目录和文件进行读写、删除、改名等操作。FSO对象来自微软提供的脚本运行库scrrun.dll中。

在ASP.NET中我们发现这一问题仍然存在，并且变得更加难以解决。这是因为.NET中关于系统IO操作的功能变得更加强大，而使这一问题更严重的是ASP.NET所具有的一项新功能，这就组件不需要象ASP那样必须要使用regsvr32来注册了，只需将Dll类库文件上传到bin目录下就可以直接使用了。这一功能确实给开发ASP.NET带来了很大的方便，但是却使我们在ASP中将此dll删除或者改名的解决方法失去效用了，防范此问题就变得更加复杂。需要进一步了解的朋友可以看＜asp.net虚拟主机的重大隐患＞一文，本文就不再重复。只针对此问题引出虚拟主机的安全设置。

网上提出针对此问题用Microsoft .NET Framework Configration设置System.io的对目录读取的权限，经过我们长时间的测试没有成功，可能是.net framework1.1机制改革了？

废话不说。先说说解决的思路：在 IIS 6 中，Web 应用程序的工作进程设置为以进程标识“Network Service”运行。在 IIS 5 中，进程外 Web 应用程序则设置为以 IWAM_＜服务器名＞帐户运行，这个帐户是普通的本地用户帐户。

Network Service 是 Windows Server 2003 中的内置帐户。了解 IIS 5 上的本地用户帐户（IUSR 和 IWAM）与这个内置帐户之间的区别是非常重要的。Windows 操作系统中的所有帐户都分配了一个 SID（安全标识，Security ID）。服务器是根据 SID，而不是与 SID 相关的名称来识别服务器上所有帐户的，而我们在与用户界面进行交互时，则是使用名称进行交互的。服务器上创建的绝大部分帐户都是本地帐户，都具有一个唯一的 SID，用于标识此帐户隶属于该服务器用户数据库的成员。由于 SID 只是相对于服务器是唯一的，因此它在任何其他系统上无效。所以，如果您为本地帐户分配了针对某文件或文件夹的 NTFS 权限，然后将该文件及其权限复制到另一台计算机上时，目标计算机上并没有针对这个迁移 SID 的用户帐户，即使其上有一个同名帐户也是如此。这使得包含 NTFS 权限的内容复制可能出现问题。

内置帐户是由操作系统创建的、一类较为特别的帐户或组，例如 System 帐户、Network Service 和 Everyone 组。这些对象的重要特征之一就是，它们在所有系统上都拥有一个相同的、众所周知的 SID。当将分配了 NTFS 权限的文件复制到内置帐户时，权限在服务器之间是有效的，因为内置帐户的 SID 在所有服务器上都是相同的。Windows Server 2003 服务中的 Network Service 帐户是特别设计的，专用于为应用程序提供访问网络的足够权限，而且在 IIS 6 中，无需提升权限即可运行 Web 应用程序。这对于 IIS 安全性来说，是一个特大的消息，因为不存在缓冲溢出，怀有恶意的应用程序无法破译进程标识，或是对应用程序的攻击不能进入 System 用户环境。更为重要的一点是，再也不能形成针对 System 帐户的“后门”，例如，再也无法通过 InProcessIsapiApps 元数据库项利用加载到 Inetinfo 的应用程序。

Network Service 帐户在创建时不仅仅考虑了在 IIS 6 中的应用。它还具有进程标识 W3WP.exe 的绝大部分（并不是全部）权限。如同 ASPNET 用户为了运行 ASP.net 应用程序，需要具有 IIS 5 服务器上某些位置的访问权限，进程标识 W3WP.exe 也需要具有类似位置的访问权限，而且还需要一些默认情况下没有指派给内置组的权限。

为了管理的方便，在安装 IIS 6 时创建了 IIS_WPG 组（也称为 IIS 工作进程组，IIS Worker Process Group），而且它的成员包括 Local System（本地系统）、Local Service（本地服务）、Network Service（网络服务）和 IWAM 帐户。IIS_WPG 的成员具有适当的 NTFS 权限和必要的用户权限，可以充当 IIS 6 中工作进程的进程标识。

因此，Network Service 帐户提供了访问上述位置的权限，具有充当 IIS 6 工作进程的进程标识的充足权限，以及具有访问网络的权限。

Msdn上说：在 Windows Server 2003 中，用户上下文称为 NETWORK SERVICE。这些用户帐户是在 .NET Framework 安装过程中创建的，它具有唯一的不易破解的密码，并仅被授予有限的权限。ASPNET 或 NETWORK SERVICE 用户只能访问运行 Web 应用程序所需的特定文件夹，如 Web 应用程序存储已编译文件的 \bin 目录。

要将进程标识设置为特定用户名，以取代 ASPNET 或 NETWORK SERVICE 用户标识，您提供的用户名和密码都必须存储在 machine.config 文件中。

但是根据实际情况，asp.net的system.io可以无限制访问不设防的服务器路径。不知道这算不算一个ms的重大漏洞。而且根本不能使iis以machine.config的用户执行asp.net程序。J

如何解决呢？答案就是—应用程序池。

IIS 6.0 在被称为应用程序隔离模式（隔离模式）的两种不同操作模式下运行，它们是：工作进程隔离模式和 IIS 5.0 隔离模式。这两种模式都要依赖于 HTTP.sys 作为超文本传输协议 (HTTP) 侦听程序；然而，它们内部的工作原理是截然不同的。

工作进程隔离模式利用 IIS 6.0 的重新设计的体系结构并且使用工作进程的核心组件。IIS 5.0 隔离模式用于依赖 IIS 5.0 的特定功能和行为的应用程序。该隔离模式由 IIs5IsolationModeEnabled 配置数据库属性指定。

您所选择的 IIS 应用程序隔离模式对性能、可靠性、安全性和功能可用性都会产生影响。工作进程隔离模式是 IIS 6.0 操作的推荐模式，因为它为应用程序提供了更可靠的平台。工作进程隔离模式也提供了更高级别的安全性，因为运行在工作进程中的应用程序的默认标识为 NetworkService。

以 IIS 5.0 隔离模式运行的应用程序的默认标识为 LocalSystem，该标识允许访问并具有更改计算机上几乎所有资源的能力。

IIS 功能

IIS 5.0隔离模式宿主/组件

工作进程隔离模式宿主/组件

工作进程管理

N/A

Svchost.exe/WWW 服务

工作进程

N/A

W3wp.exe/工作进程

运行进程内ISAPI 扩展

Inetinfo.exe

W3wp.exe

运行进程外ISAPI 扩展

DLLHost.exe

N/A（所有的 ISAPI 扩展都在进程内）

运行ISAPI筛选器

Inetinfo.exe

W3wp.exe

HTTP.sys 配置 Svchost.exe/WWW 服务

Svchost.exe/WWW

服务

HTTP 协议支持

Windows内核/HTTP.sys

Windows 内核/HTTP.sys

IIS配置数据库

Inetinfo.exe

FTP

Inetinfo.exe

NNTP

Inetinfo.exe

SMTP

Inetinfo.exe

由此可见，我们只能使用工作进程隔离模式解决.net的安全问题。

默认情况下，IIS 6.0在工作进程隔离模式下运行，如图五所示。在这种模式中，对于每一个Web应用，IIS 6.0都用一个独立的w3wp.exe的实例来运行它。w3wp.exe也称为工作进程（Worker Process），或W3Core。

可靠性和安全性。可靠性的提高是因为一个Web应用的故障不会影响到其他Web应用，也不会影响http.sys，每一个Web应用由W3SVC单独地监视其健康状况。安全性的提高是由于应用程序不再象IIS 5.0和IIS 4.0的进程内应用那样用System帐户运行，默认情况下，w3wp.exe的所有实例都在一个权限有限的“网络服务”帐户下运行，如图六所示，必要时，还可以将工作进程配置成用其他用户帐户运行。

对，这里，这里就是我们解决的.核心。

我们把每一个网站都分配一个独立的应用程序池，并赋予不同的权限。不就能解决这个问题了吗？

具体如何做呢，下面我就针对建立一个网站来做一个示范：

首先，我们为网站创建两个用户（一个是app_test_user、密码为appuser,一个是iis_test_user、密码为iisuser）

1. 打开计算机管理器

2. 单击控制台树中的用户→计算机管理→系统工具→本地用户和组→用户

3. 单击“操作”菜单上的“新用户”输入用户名为。app_test_user、密码为appuser

4. 在对话框中键入适当的信息。

5. 选中复选框：

用户不能更改密码

密码永不过期

6. 单击“创建”，然后单击“关闭”。

按照此方法在创建iis_test_user账户

然后分别把app_test_user添加到iis_wpg组，把iis_test_user添加到Guests组。删除其他组。

然后，建立相应的应用程序池。

依次打开Internet 信息服务→本地计算机→应用程序池→新建→应用程序池

新建一个名字为test的应用程序池

编辑test应用程序池的属性→标示→配置→用户名→浏览→把用户名改为我们刚才建立的app_test_user并输入相应的密码

其次建立相应的网站。

依次打开Internet 信息服务→本地计算机→网站→新建→test的网站，目录为d:\test →编辑test网站的属性→主目录→应用程序池→app_test_user →目录安全性→身份验证和访问控制→编辑，选择我们刚才建立的iis_test_user,并输入相应的密码iisuser→保存并退出。

最后设定服务器的安全。

C:只给administrators和system完全控制的权利，删除掉其他所有的权限，不替换子目录

C:\Documents and Settings继承父项,并替换子目录。

C:\Program Files继承父项,并替换子目录，并把C:\Program Files\Common Files\Microsoft Shared继承属性删除并复制现有属性，增加users的读取权限并替换子目录（这样做是为了能够让asp,asp.net使用access等数据库）。

C:\windows删除继承,并复制现有属性,只给予administrators,system完全控制和users读取的权限并替换子目录

其余所有的盘都只给于administrators和system用户的完全控制权限，删除其他所有用户并替换子目录。

D:\test（用户网站目录）继承现有属性并增加app_test_user和iis_test_user完全控制的权限并替换子目录。

以后每增加一个网站都以此类推。

但是，至此，system.io还是对c:\windows又读取权限的，（怀疑network servers用户属于users组，但是好多服务都要使用users组来执行的，所以不能把c:\windwos去掉users组的读取权限）但必须知道系统路径，有两种方案解决。

1、再安装系统的时候使用无人值守安装，更换c:\windows默认安装路径，如更改为c:\testtest(要符合dos的命名规则，不能超过8个字符)。这个是必需的

2、以下位置具有指派给 IIS_WPG 的权限：

%windir%\help\iishelp\common – 读取