构建安全的.NET系统

2019-11-17 04:42:11

字体：大中小

来源：转载

供稿：网友

　　自从1999年夏季，每个出自Redmond的Microsoft软件产品都使用了.NET品牌。.NET 品牌产品由一系列运行在windows 2000操作系统中的优秀商业应用软件组成。

这些应用软件包括SQL Server 2000、Commerce Server 2000、 BizTalk Server 2000、Exchange 2000 Server、application Center 2000 Server、Mobile Information 2001 Server以及Internet Security and Acceleration (ISA) Server 2000。　　Microsoft同时也用.NET品牌来命名新一代.应用软件开发体系和方法，也就是所谓的.Net框架。由于Microsoft对.NET品牌技术的定义非常宽范，它将影响到所有现存的基于Microsoft 技术的IT系统或者Microsoft的要害型应用软件。　　当你规划你的.NET基本结构时，你需要考虑使用哪些安全服务。最基本的安全服务应该包括可靠的身份验证、数据保密和数据完整性保护（用于通过网络发送的数据和存储在任何类型存储介质上的数据）、认可服务及antireplay（反数据窃听）服务。这些服务以及提供服务的技术对任何系统结构——不仅仅是.NET——都很重要。当然，.NET特有的安全功能也还存在。不过，我们希望能够保护.NET系统结构的所有部分，而不仅仅是利用.NET各z应用软件中自带的安全功能进行系统防护。　　为实施这些基本的安全服务，你需要把握几项要害技术和基本设计原理。如何设置安全区和防火墙、“侵入检测系统”（IDSs）、身份验证、身份验证授权、公钥基本结构（PKI）以及如何强化平台安全（hardening）对你的.NET基本结构是非常重要的。　　一个典型的.NET基本结构　　一个典型的.NET基本结构。需要保护的组件有Web服务器、商务对象服务器、目录、证书颁发服务器（CAs）、企业资源规划（ERP）系统、数据库以及组件间的通信连接。　　在.NET系统中，内部和外部客户完全基于Web访问.NET基本结构。一个典型的.NET基本结构将包括不同的可用性和负载均衡解决方案。在Web服务器级，捆绑在Win2K Advanced Server、Win2K Datacenter Server和Application Center 2000上的“网络负载均衡服务”（NLBS），可提供高可用性和负载均衡能力。SQL Server数据库和ERP系统则支持群集。需要注重的是系统同时也包括一个COM+的商务对象群集。你可使用Application Center 2000来集成和治理该COM+群集及Web服务器的NLBS。（　　在我撰写此文的时候，要对有某些.NET应用软件功能进行深入的讨论是不太可能的，这是因为那些功能的一些细节还不清楚。然而，鉴于Microsoft正在Win2K上建立.NET基本结构，我们可以认为，.NET将进一步开发Win2K的安全功能。同时，随着基于Internet 的协议的重要性日益增强，我们可以认为，将主要通过标准Internet协议（例如HTTP、SMTP、“轻量级目录访问协议”—LDAP），访问.NET基本结构组件。　　安全区和防火墙　　当你规划你的安全.NET基本结构，你将需要评估一下当前公司的安全区和防火墙。你的.NET基本结构可能需要你作一定的改变。即使你构建的应用软件不会与外界接触，你也需要考虑使用防火墙。内部防火墙可以保护站点或有特定安全要求的部门，可以限制对你内部网络某些部分的访问（在入侵者破坏防火墙的情况下，内部防火墙将是你外部安全界线的一部分）。　　当你设计系统结构的时候，可能会碰到两个涉及到安全区和防火墙的常见问题。第一个问题是，我应该将数据和服务器放在何处？用来存放数据和服务器的安全区取决于你正使用的数据或服务器的目的。请评估你的服务器处理和存储的数据的机密程度，然后在你信任的安全区内存储机密的客户数据。　　假如你的公司在网络拓扑中使用了不设防区域（DMZ），问题将复杂一些。尽管你应该在DMZ中只存放公用数据。然而，即使是公用数据的也需要保护其完整性。在2000年美国总统选举期间，两个候选人都不会想让入侵者改变CNN公布在其Web站点上的选票数。（不过，也许Al Gore并不会介意。）　　第二个问题是，我该如何处理“远程过程调用”（RPC）及“安全套接字层”（SSL）/“传输层安全”（TLS）通信，使防火墙两边的应用实体可以进行通信。许多商业Web站点使用SSL/TLS为消费者提供一套基本的安全服务。该套基本安全服务通常包括服务器身份验证、客户身份验证、以及对SSL客户端与服务器之间传输数据完整性和保密性的保护。为了在在防火墙的层次处理SSL通信，你可以采取以下两种方法之一：SSL隧道操作，或SSL 桥接操作。大多数商业防火墙支持SSL隧道操作，使用HTTP CONNECT消息来告诉防火墙忽略特定的SSL会话的具体内容，只是简单地转发SSL包。在SSL桥接设置中，防火墙对SSL是敏感的，并保留正确的SSL证书。防火墙扮演SSL隧道终点的角色。SSL桥接操作不仅对在防火墙级处理SSL通信，而且让通信通道的公开（比如未被信任的区域）部分（与不支持SSL的应用相连接的部分）也可以使用SSL，因此不失为一种很好的解决方案。　　RPC答应客户端使用远程应用软件相互联系。所有涉及.NET基本结构的组件都可使用RPC通信。值得非凡关注的是，使用RPC在Microsoft的分布式组件模型（即DCOM和COM+）中实现组件之间的通讯，以及Active Directory（活动目录）的复制。　　RPC很轻易进行设置——假如不涉及防火墙的话。RPC的一个令人讨厌的特性就是使用动态入站端口，这使得用户无法猜测即将使用哪个端口。出于安全因素考虑，很少有防火墙治理员愿意打开所有可能的端口。有关这个问题的更多信息，请参见Microsoft文章“HOWTO: Configure RPC Dynamic Port Allocation to Work with Firewall（如何配置RPC动态端口分配使其与防火墙协同工作）”（http://support.microsoft.com/support/kb /articles/q154/5/96.asp）。　　那么，如何处理用于DCOM和COM+通讯的RPC和防火墙的呢？首先，你决不能使用RPC将Internet客户连接到你的.NET系统。相反，应选择一个基于HTTP的解决方案。只要不使用SSL或ip安全（IPSec），HTTP就比较轻易控制，并且使用固定入站端口（缺省情况下为端口80）。然而，有时你需要考虑，如何设置RPC使其能通过防火墙进行DCOM和COM+通信。设想一下, 在基本结构中，你需要在DMZ中的一个Web服务器和一个COM+商业对象服务器之间进行COM+通信。在这种情况下，你可以使用RPC，通过隧道TCP或简单对象访问协议（SOAP）实现组件之间的通讯。　　隧道TCP在DCOM通讯序列开始时，添加了一种基于HTTP的“握手”（handshake）。“握手”之后，隧道TCP在TCP上发送普通的DCOM包，不受HTTP的干涉。隧道TCP依靠于RPC_CONNECT消息，并需要一个RPC代理。要在Win2K上安装RPC代理，请打开控制面板的添加/删除程序项，添加COM Internet Services PRoxy （CIS代理）Networking Service.(COM Internet服务代理网络服务)。要在Win2K或Windows NT 4.0客户端配置隧道TCP，可以使用dcomcnfg.exe 配置工具。有关配置隧道TCP和CIS代理的具体信息，请参见Marc Levy在MSDN上发表的文章“COM Internet Services”（http://msdn.microsoft.com/library/backgrnd /Html/cis.htm）。尽管隧道TCP和CIS代理解决了防火墙问题，但是它们依靠于Microsoft平台。　　SOAP，.NET框架的一个时髦说法，是一项相当新的技术。Microsoft、Lotus、及IBM的专家们将SOAP定义为一项独立于平台的协议。SOAP的一个主要优势就是，它提供了一种使用HTTP协议消息来传送RPC通讯的方法。换句话说，SOAP答应客户端使用HTTP协议与远程的基于组件的应用软件进行通讯。　　为将RPC信息嵌入到HTTP中，SOAP使用了xml编码。区别于隧道TCP，SOAP依靠于HTTP 协议获得远远多于初始“握手”的信息。有关SOAP的更多信息，请参见Aaron Skonnard在MSDN上发布的文章《SOAP: The Simple Object access Protocol》（http://msdn.microsoft.com/library/periodic /period00/soap.htm）。　　另外一个基于RPC的应用，在.NET系统结构安全领域非凡令人感爱好，那就是同一域内的域控制器（DC）之间的活动目录复制，这些域控制器是不同安全区的成员。到目前为止， Microsoft还不支持将SMTP协议用于域名相关的信息复制。为解决这一问题，你可以设置基于IPSec的隧道解决方案。IPSec答应你在网络层实施隧道操作。为建立通过防火墙的IPSec隧道，你需要打开以下端口：　　用于DNS通信的53/TCP和53/UDP

　　用于Internet密钥交换（IKE）通信的500/UDP
　　用于Kerberos v5 通信的88/TCP和88/UDP（当你未使用预共享密钥或基于证书的身份验证方法时）　　同时，你需要打开防火墙，以支持IPSec Encapsulating Security Payload（ESP,封装安全负载）——协议50，以及IPSec Authentication Header(AH，身份验证头)——协议51。　　入侵检测系统（IDS）　　在过去的一年里，IDS已经成为一种必须的安全功能。作为任何.NET基本结构安全的必备之物，IDS执行三个主要任务：

　　IDS监控出现在计算机和网络上的事件。


　　IDS收集并分析这些事件。在分析的基础上，IDS可检测到由事件汇报Web站点、IDS服务或软件供给商提交的报告中提到的攻击，该类攻击已经渗透到你的安全体系中的其他保护层。

　　IDS对检测到的攻击做出响应。该响应可包括通知治理员、连接终止或高级数据收集，即从更多的数据源收集比平时更多的信息。　　使用IDS你不仅可以检测到来源于公司外部的攻击，还可以检测到上报的内部攻击。太多的公司低估了内部合法用户攻击的危险性。举个例子，某个不满的雇员可能会启动Denial of Service（DoS）来攻击公司的目录。你也可以利用IDS建立一套服务，该服务可以弥补企业安全策略和IT基本结构的安全组件之间的缺口。由于IDS是对攻击做出响应的，它可动态强化企业的安全策略。　　IDS有两个基本类型——基于主机的IDS和基于网络的IDS 。基于主机的IDS主要扫描并监控本地系统的状态和数据。在Win2K的环境下，基于主机的IDS服务器通常监控日志事件、文件系统事件及注册事件。基于网络的IDS系统则监控网络通信——可将之看为一个高级“嗅探器”。基于主机的IDS的一个最常见的例子是Symantec（前身是AXENT技术）的Intruder Alert（入侵者警报）。Symantec同时提供基于网络的解决方案，叫做NetProwler。Internet Security Systems（ISS）公司则提供一种称为Real-Secure（实时安全）的产品，它是一种既基于主机又基于网络的IDS。　　身份验证　　你的.NET基本结构可能包括不同类型的客户端和治理员界面。由于这些取决于界面的用途和从这些界面可访问的数据，它们可能需要不同等级的身份验证。例如，有些界面和数据是公用的，不需要任何的身份验证。　　对身份验证协议的选择取决于你正在处理的访问协议和客户端应用软件。在基于RPC的连接中，你可以使用Kerberos或NT LAN Manager（NTLM）。基于HTTP的连接给你更多选择：基本身份验证或简要身份验证、Kerberos、NTLM或基于证书的客户端身份验证。假如你有来自不同供给商的不同种类的客户端应用软件，请不要选择NTLM或Kerberos。（NTLM是Microsoft专用的协议，而Kerberos是开放式的标准，但应用不广）。同时请记住，只有当用户已经登录Windows域时，Kerberos和NTLM才在HTTP上可用。假如你的多数客户是通过Internet连接的，对小用户群，你很可能倾向于在SSL上使用基本身份验证。对大用户群，你可能应考虑补充使用标准身份验证协议，该协议带有一种基于自定义窗体或cookies的身份验证方法。甚至你可能要考虑执行使用Microsoft护照—— 一项旨在为大型Internet环境服务的简单登录（single sign-on）（SSO）技术。　　身份验证解决方案的质量，很大程度上取决于该解决方案用来识别实体对象时考虑的因素的数量。一个只依靠于用户ID和密码的简单解决方案，比同时依靠于智能卡和PIN码的解决方案在身份验证方面的质量要低的多。前者属于单因素身份验证方法，而后者是双因素身份验证方法。对安全要求较高的.NET的解决方案，你甚至可能要考虑三因素身份验证方法，包括用户名、持有物件（智能卡）和生物数据（指纹）的验证。　　影响身份验证解决方案质量的另外一个因素，就是背后的加密技术。身份验证协议，例如Kerberos或NTLM，都比SSL客户端基于证书的身份验证方案轻易遭到破坏。前者使用对称密码，而后者使用非对称密码。有个例外，就是Win2K的智能卡登录过程使用的Kerberos PKINIT。Kerberos协议的这个扩展技术同时使用对称和非对称密码。（使用非对称密码可能需要首先打开PKI。）　　当你正为.NET基本结构设计身份验证解决方案时，你还需要考虑凭据（credential）数据库。凭据数据库的设置再次取决于使用身份验证凭据的目的（相比包含发射核导弹密码的数据库，公用应用软件的密码数据库需要较少的保护）。在Windows环境下，活动目录是通常存储凭据的场所。你会选择将所有活动目录服务器上的凭据存放在受信任的区中，或者选择将活动目录服务器上的部分凭据存放在DMZ中。在后一种情况中，你或者为DMZ定义一个单独的活动目录森林，或者为DMZ定义一个单独的活动目录域，并在受信任的区使用你的活动目录森林对它进行集成。我推荐使用前面的方法（即，在DMZ中定义独立的活动目录森林），这是因为它完全将受信区的帐号与DMZ的帐号屏蔽开来了。同时，该方法不需要使用防火墙上的RPC保护你的受信网络，而答应你在SSL上使用LDAP建立内部活动目录域和DMZ的活动目录域之间的安全同步机制。　　身份验证授权　　当你正设计多等级.NET基本结构时，需要考虑的另外一项基本技术就是身份验证授权（Authentication Delegation）。多层.NET应用软件包括多个身份验证层次——例如客户端和Web服务器之间、Web服务器和COM+商务对象服务器之间、COM+商务对象服务器和数据库服务器之间等。假如你想使用用户身份来设置对数据库服务器上数据的访问控制，你所使用的身份验证协议必须支持授权。换句话说，身份验证协议需要有能力在机器之间转发用户凭证。每台机器都使用客户身份来对下一台机器验证身份。　　说明了授权支持是如何跟你所使用的身份验证协议相关联的。举个例子，假设你正使用基本身份验证来验证某用户身份，该用户通过从他/她的浏览器连接到远程服务器上的Web服务器工作。为对一台与该Web服务器相邻的服务器（例如Exchange 服务器）进行身份验证，Web服务器可重复使用用户身份。假如安装了AD（同时Kerberos身份验证协议可用），与Web服务器相距多个节点的服务器也可以使用该用户身份来身份验证。Web服务器进程可以使用Kerberos和客户端凭证来对COM+服务器进程进行身份验证。按此顺序，COM+服务器也可以使用Kerberos和客户身份来对Microsoft SQL服务器进程进行身份验证（仍是在另一台机器上）。注重，当你匿名访问Microsoft IIS，并且答应密码同步时，你不能授权给IUSR的servername帐号。当你使用的是基于SSL/TLS的证书身份验证，且证书映射在AD中已经定义时，结果也是一样。同时记住，NTLM不支持授权。　　说明了如何在一典型的基于Win2K的Intranet环境下设置Kerberos授权。所有组件都可使用RPC来实现通讯。客户端界面是基于浏览器的，从而通过HTTP与Web服务器实现通讯。同时，用户已经通过Kerberos或NTLM登录到域。在Internet的设置过程中，客户端也通过HTTP通讯，但一般不会登录到域。然而，在Internet上使用Kerberos或NTLM并不是一个好的想法——这些身份验证协议在大型环境下灵活度不大，且需要一个在线并且可以信任的第三方的存在。　　为实现从浏览器连接到数据库服务器使用Kerberos，你需要满足以下条件：　　所有相关软件必须可访问或知道如何使用Negotiate Security Support Provider（SSP，协商安全支持供给方）和Kerberos SSP。SSP是一种软件模块，它为应用软件及其开发人员抽象出身份验证方案的内核技术。Negotiate SSP是一种非凡的程序，负责协商客户端和服务器之间的身份验证协议（例如，Kerberos或NTLM）。撰写此文的时候，Kerberos SSP只适用于Win2K平台。Microsoft Internet EXPlorer（IE）5.5和IE 5.0、Internet Information Services （IIS）5.0、SQL Server 2000、Exchange 2000、以及COM+等都知道如何使用Negotiate和Kerberos SSPs。　　用户必须在活动目录中有帐号，并且活动目录没有启用Account is sensitive and cannot be delegated（帐户属于敏感帐户，不能被授权）属性。为检查这项设定，请启动Microsoft Management Console（MMC）Active Directory Users and Computers snap-in（Microsoft治理控制台的Active Directory用户及计算机的治理单元），访问一个AD用户对象属性表单，并选择Account选项页面。运行IIS和SQL服务器的服务帐号，还有用于COM+应用软件的身份，都必须在AD中有定义。IIS服务帐号（缺省情况下是机器帐号）和COM+应用软件身份必须得到信任以进行授权。你可以在Account页面设置帐户是得到信任可以授权的。为设置机器的帐号，可打开活动目录用户及计算机的治理单元中的当前对象的General选项页面。　　Web服务在活动目录中必须拥有有效注册的“Service Principal Name”（SPN，服务主要名称）。假如Web服务的名称不同于IIS计算机名称，请确保使用Microsoft Windows 2000 Resource Kit中的setspn.exe实用工具来注册自定义的SPN。　　COM+应用软件必须支持Delegate impersonation level授权假冒级别　　尽管身份验证授权在Win2K环境下轻易设置，我仍强烈建议，在你开始对.NET基本结构实施安全措施之前，对它进行测试，尽量熟悉。比起Active Directory Users and Computers GUI的配置选项，身份验证授权后面的技术非常复杂。　　公共密钥（PKI）基本结构　　PKI给你提供了一套服务，它可对多种.NET应用软件和服务提供强有力、非对称并且基于密码的安全服务。举个例子，你可以使用PKI，在BizTalk Server SMTP连接上提供安全的MIME（S/MIME）服务，或者对访问你的Web站点的用户提供强有力的身份验证和安全通道服务（即，基于SSL和基于TLS的通道服务）。　　在.NET系统中设置PKI，例如PKI系统，是件复杂的事情。在此种情形下，PKI包括四个主要组件：脱机的根CA、联机的从属CA、运行在Web服务器上的证书注册Web站点（针对Internet用户）、以及一套支持PKI的客户端、机器和应用软件。受信区中的PKI用户和应用软件直接从联机发行的CA中获得证书。在此设置过程中，你将需要再次处理RPC和防火墙的问题——注册Web站点使用RPC与联机发行的CA进行通讯。　　.NET基本结构的“建筑师”必须能回答与PKI相关的三个要害问题。首先，PKI信任模型将是什么模样的？PKI信任模型定义了CAs和支持PKI的实体之间的信任关系。假如你正专注于商业CAs或外部合作伙伴，他们已经在适当的位置用PKI了，设置一个信任模型可能会困难重重。信任模型必须能回答上这个问题，哪个CA值得信任？并且，更为重要的是，哪个证书或公钥值得信任？尽管你可以使用加密技术来检验大多数PKI的信任关系，你仍不能检验支持PKI的实体和可信的CA发放站点之间的信任关系。支持PKI的实体和可信的CA发放站点之间的信任观念类似于人类之间的信任。你信任人们帮你做某事，那是因为你了解他们并且相信他们会做好。与之类似，你相信一个CA发放站点将发行值得信任的证书，因为你知道，经营CA服务的公司有做好这类事情的声望，或者因为CA公司的某些行动已经让你相信它是值得信任的。

第二个问题是，你将部署来自内部的PKI还是外购的？抑或是混和的？假如你依靠于商业CA，你会变得对其极端依靠（因为你已经向一家外部公司透露了部分安全结构的治理方法）。假如你使用这种PKI，对那些涉及高度机密或财政信息的应用软件提供安全保障，那么这种高度依靠性将让人无法忍受。　　第三个问题是，你将如何在支持PKI的实体之间交换证书和证书吊销列表？你需要决定你将如何设置PKI，以使证书和证书吊销列表（CRL）对所有支持PKI的实体都有效。在小环境下，你可以使用单独的LDAP目录来访问，例如内部Win2K的AD。但假如你考虑多目录情况（可能包括你自己的和每个正使用你的.NET 解决方案的合作伙伴的目录），情形会变得复杂。　　尽管在你的.NET基本结构中设置PKI时，你还需要应付许多其他的挑战，单上述这些问题是最重要的部分。好好预备吧，记住，设计PKI不会像在Win2K 下运行CA安装程序那么简单。　　平台安全强化　　平台安全强化涉及到你的.NET基本结构运行的Win2K平台的安全性。强化操作系统平台的安全是所有操作系统的治理员面对的永无休止的一项任务。　　主要的平台安全强化任务是，随时使用最新的服务包和安全补丁程序。为部署服务包和安全补丁程序，你可以使用“Microsoft系统治理服务器”（SMS）或“组策略对象”（GPO）上的应用软件部署功能。　　2000年颇受关注的一个平台安全强化主题，就是保护免受DoS的攻击。从系统可用性观点看来，DoS攻击可对你的.NET基本结构造成严重损害。你需要清楚了解最新的DoS攻击类型，Microsoft和“计算机紧急响应小组”（CERT）在其Web站点上定期发布DoS信息。Microsoft提供了一套注册表子键（subkey）（例如SynAttackProtect、EnableDeadGWDetect、EnablePMTUDiscovery），可强化TCP/IP堆栈对DoS攻击的抵制。有关这些密钥的附加信息，请参见Microsoft文章《Security Considerations for Network Attacks》（http://www.microsoft.com/technet/security/dosrv.asp）。　　有个很好的工具可帮助你自动实现服务器的安全强化，就是Win2K的“安全配置和分析”（SCA）工具。有关Win2K安全强化的更多信息，请参见Microsoft的安全Web站点（http://www.microsoft.com/technet/security），和Windows IT安全Web站点（http://www.ntsecurity.net）。有个优秀的最新安全事件信息源是“CERT协调中心”（CERT/CC），在http://www.cert.org。　　入侵者警报　　我已经描述了一些当你正为你的.NET基本结构设计时，需要牢记在心的要害技术和设计原理。当然，还有其他
的安全技术和设计原理，但我讨论的解决方案代表一套“基本的”安全保障措施。假如你不认真对待每条建议，你可能就会错过提高安全的重要机会。更糟糕的是，你的最终设计可能会成为网络入侵者的天堂。

上一篇：用XMLTextReader类加速.NET中XML存取

下一篇：软件架构训练基础教程之使用标准