是不是很担心Web系统架构存在的潜在问题？那不妨看看三名IT系统专家如何在Web接入、配置密码等小细节上处理此类问题的。

　　Web架构配置无小事

　　不用默认密码

　　企业有多少关键系统和应用拥有Web接口？据CyberDefenses公司的负责人Phil Dolbow声称，如今几乎每个系统和应用都拥有Web接口。Web接口很普遍，但如果配置不正确就有可能遭到破坏，因为有许多企业在安装好系统后没有更改默认的登录凭证（credential）。Dolbow所在的咨询公司专门提供信息保障及IT安全的信息服务，所开展的工作绝大部分是与联邦政府（主要是军方）合作的。他概述了在许多客户那里看到的不正确配置Web接口的常见问题，还建议该如何解决此类问题。

　　“这类问题见多了。总的来说，我发现的问题大家都能猜得出来，比如缺少用户培训、系统配置不当或安全项目缺少资金。常常见到的最大问题其实是很容易被发现、很容易解决的，但如果不能发现则会带来严重隐患: 那就是Web接口。我们在进行评估时，总是扫描寻找没有设置好的Web接口。如今，几乎每个系统都有Web接口; 存储区域网络（SAN）、不间断电源（UPS）系统、打印机、警报系统、电话、备份系统、服务器等等硬件设备。要是在默认凭证的情况下启用这些Web接口，就有可能出现很严重的问题。”

　　Dolbow说，下面这几个例子是多次发生的问题。某公司之前没有用过存储区域网络，但业务对磁盘空间的需求不断增长，他们最近也买了一个。公司内没人知道该如何配置SAN，而供应商又坚持安装了系统，并让客户自行设置所安装系统上的用户名和密码。该公司在安装好系统之后，再也很少关注配置问题，结果有一个关键任务设备始终使用默认的出厂登录凭证。这是非常危险的，许多公司如此简单地配置关键系统。不怀好意的人有可能破坏逻辑单元号（LUN）、删除数据，这会引发各种问题。

　　同一种场景还出现在对待不间断电源系统的问题上。不久前，CyberDefenses公司评估了一家在IT配置以及在安全上不惜下血本的大型政府机构，它们拥有最安全的系统。在CyberDefenses评估前的几个月，该机构请IT承包商更换了所有UPS系统，包括为其主计算机机房的所有关键服务器提供电源保障的几台UPS。IT承包商把这些UPS系统连接到网络上，以便可以远程管理及监测这些系统。Dolbow显示了一份客户报告的屏幕截图，表明他们可以随意登录到Web接口（借助管理员权限，使用默认凭证）。当鼠标光标悬浮在关键业务的关闭按钮上可随时结束进程时，这才能足够引起客户的注意。

　　解决方案

　　针对此种情况，解决办法如下:

1. 对Web服务器/接口定期执行端口扫描;

2. 如果Web接口没有必要，就关闭这项服务;

3. 更改凭证、尽量使用https访问;

4. 只允许授权的管理员工作站可以访问;

5. 加强防火墙限制;

6. 监测日志。

　　分配不同权限

　　员工拥有的系统访问权限是否会导致企业面临安全风险？一家大型制造公司的高级IT经理详细讲述了他如何重新配置访问生产系统的机制，以便限制性更强、更容易审计。

　　“我们IT员工大多可以使用‘用户账户’全面访问所有生产系统。测试人员在一次安全审计和渗透测试中抓住了这个漏洞，最后拥有了公司的Windows Domain以及大多数生产数据库服务器的访问权限。现在，我们从域管理员、数据库管理员账户及Application Root Account等账户中取消了每个人的‘用户账户’。如果技术系统管理员让敏感的系统和数据需要常规访问，就要设置不同的账户来访问，并使用安全性很强的密码。我们使用一些审计工具和Cyber Ark公司的密码保险箱工具，以便审计该账户的所有使用活动。”

　　该IT管理人员说，他们的许多应用/数据库管理人员需要对生产系统进行大量不太常规的访问。对这些系统而言，他们取消了所有常规的管理员访问，而换成了选择性的“应急账户”（firefighter accounts），这类账户比较普通。这些账户存储在密码保险箱中，由一个强密码加以保护。还有这样一个过程: 输入票证（ticket），获得审批，并记录在他们的票证记录系统中。对于高度敏感的项目，密码保险箱还要求实施几道审批环节; 还需要输入基本的票证编号、说明理由，从而在增强了票证记录系统之后才可发放密码。密码发放后系统可进行设置，在一段时间后自动重置; 或在请求者“将密码返回入库”后重置。

　　解决方案

　　一般来说，密码保险箱控制着服务器和PC系统上嵌入式的本地管理员账户、服务账户以及嵌入到系统中的数据库访问账户和应用账户。这些账户通常从来不会受到密切关注。在过去，不破坏许多系统就无法更改密码。许多企业采用密码保险箱工具对这些账户和密码进行控制后，可以顺利地定期轮换。

　　最后，当然是需要备份，有了这些账户和密码的副本以便灾难恢复。如果采用这样的策略，企业的灾难恢复以及业务连续性计划也更严密了，可进一步配置系统。

　　处理好隐私难题

　　如果验证机制和数据被设置成面向特定客户的，用户能把Web系统作为门户来运行吗？美国中西部一家商业管理咨询公司的高级.Net架构师James Ashbaugh当时就遇到了这个问题。这家公司有几个客户在运行相同的系统代码，而数据存放在不同的物理设备中。由于他们的客户都是同行业内相互竞争的企业，所以数据完整性至关重要，Ashbaugh关注的是如何正确配置系统。

　　他们使用的系统环境如下。

●  约500至1000个外部用户通过思杰产品来连接;

●  微软网络;

●  面向域控制器、Web Servers和SQL Servers的Windows 2003 Server;

●  SQL Server 2008。

　　门户网站基于客户端、用户角色和客户数据库数据运行。微软为ASP .Net提供了一个丰富、基于角色的模型，但该模型不是为了在门户架构下运行而设计的。于是，Ashbaugh 结合了微软在ASP.Net安全、活动目录账户/群组和SQL Security中提供的功能。

　　现在面临的难题是: 公司有多个相互竞争的客户在运行相同的系统代码，但数据存放在不同的物理SQL设备中（使用客户特定的数据库名称）。所以，虽然大家都运行相同的Web应用和中间层，但在数据库层面却具有客户特定性（大家使用相同的数据库模型）。切记: 客户通过思杰产品来连接至公司网络，所以就需要使用单次登录（即使思杰产品负责处理DMZ验证，但它并不处理Web应用的表单验证）。明白那些客户在同一个行业很重要，所以必须确保数据的完整性，因为这涉及到竞争优势。

　　难题在于，如果验证机制和数据被设置成特定客户的，如何把Web系统作为门户来验证、装载及执行？

　　Ashbaugh的应对方法如下: 在思杰产品中，他们把IE浏览器作为一个应用来共享（但通过IE安全设置和登录脚本，限制客户对外部Web的浏览）。他们不想让使用服务器的客户可以上网冲浪，或者对竞争对手发动攻击。IE的主页被设成了他们公司的门户网站，并使用委托和模拟功能。得到了思杰验证的用户，把凭证传送到门户的装载器代码类。该代码类启动验证过程，以便“验证”SQL数据库。在该数据库中，他们对所有的客户端数据库、客户用户以及角色都进行了映射。一旦装载器验证后发现这是系统中的活动用户，装载器会获得相应的数据库连接信息，然后通过用户的Web会话进行传输。

　　注意，在装载的过程中，应该对传输的信息加密，这样可发现利用跨站脚本攻击来获取其他用户的会话信息。对会话中的连接信息进行加密意味着，黑客必须实际访问物理Web服务器，还要在执行任何解密算法的时间点来访问页面文件或内存块。由于这种可能性非常小，可以在数据库连接层面支持客户的数据安全需求。在数据库中，所有连接字符串和设置都采用加密形式来存储，使用客户特定的私有密钥（经过加密的数据来自“验证”数据库）。

　　所以，鉴于该验证用户总是可以访问数据库连接信息，需要安排建立什么样的数据库连接方法。应该把用户的角色及其他安全设置也存储在会话中。一旦所有这些前端装载的逻辑完成，装载器会连接门户主页，并使用来自用户的数据库配置数据，装载器就会扩展用户特定的主页及内容。

　　现在，当用户开始通过请求及更新数据与系统进行互动时，请求会先调用“控制器”代码。该代码被服务调用，以便安排所有的系统事件。它定义了通过配置文件调用的特定存储过程。然后，使用该名字值就会调用数据库层，并请求存储过程执行。

　　解决方案

　　通过设置SQL Server用户，让存储过程适合角色，从而便于执行存储过程。所以，如果某用户不在“项目用户组”中，该用户不可以执行“GetActiveInventoryItems”存储过程。

　　在SQL Server 2008中，用户可以结合存储过程中的#C代码，所以企业可排列基于映射用户角色而返回的特定数据字段。网页上的控件可自动创建，以支持返回的用户特定内容。这意味着: 要是有一批项目，但只有两列允许该用户访问，就要针对这个角色特定的数据来调整控件。