構建安全的.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，因此不失為一種很好的解決方案?！　PC答應客戶端使用遠程應用軟件相互聯系。所有涉及.NET基本結構的組件都可使用RPC通信。值得非凡關注的是，使用RPC在Microsoft的分布式組件模型（即DCOM和COM+）中實現組件之間的通訊，以及Active Directory（活動目錄）的復制?！　PC很輕易進行設置——假如不涉及防火墻的話。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）實現組件之間的通訊?！　∷淼繲CP在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平臺?！　OAP，.NET框架的一個時髦說法，是一項相當新的技術。Microsoft、Lotus、及IBM的專家們將SOAP定義為一項獨立于平臺的協議。SOAP的一個主要優勢就是，它提供了一種使用HTTP協議消息來傳送RPC通訊的方法。換句話說，SOAP答應客戶端使用HTTP協議與遠程的基于組件的應用軟件進行通訊?！　閷PC信息嵌入到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對檢測到的攻擊做出響應。該響應可包括通知治理員、連接終止或高級數據收集，即從更多的數據源收集比平時更多的信息?！　∈褂肐DS你不僅可以檢測到來源于公司外部的攻擊，還可以檢測到上報的內部攻擊。太多的公司低估了內部合法用戶攻擊的危險性。舉個例子，某個不滿的雇員可能會啟動Denial of Service（DoS）來攻擊公司的目錄。你也可以利用IDS建立一套服務，該服務可以彌補企業安全策略和IT基本結構的安全組件之間的缺口。由于IDS是對攻擊做出響應的，它可動態強化企業的安全策略?！　DS有兩個基本類型——基于主機的IDS和基于網絡的IDS ?；谥鳈C的IDS主要掃描并監控本地系統的狀態和數據。在Win2K的環境下，基于主機的IDS服務器通常監控日志事件、文件系統事件及注冊事件?；诰W絡的IDS系統則監控網絡通信——可將之看為一個高級“嗅探器”。基于主機的IDS的一個最常見的例子是Symantec（前身是AXENT技術）的Intruder Alert（入侵者警報）。Symantec同時提供基于網絡的解決方案，叫做NetProwler。Internet Security Systems（ISS）公司則提供一種稱為Real-Secure（實時安全）的產品，它是一種既基于主機又基于網絡的IDS?！　∩矸蒡炞C　　你的.NET基本結構可能包括不同類型的客戶端和治理員界面。由于這些取決于界面的用途和從這些界面可訪問的數據，它們可能需要不同等級的身份驗證。例如，有些界面和數據是公用的，不需要任何的身份驗證?！　ι矸蒡炞C協議的選擇取決于你正在處理的訪問協議和客戶端應用軟件。在基于RPC的連接中，你可以使用Kerberos或NT LAN Manager（NTLM）?；贖TTP的連接給你更多選擇：基本身份驗證或簡要身份驗證、Kerberos、NTLM或基于證書的客戶端身份驗證。假如你有來自不同供給商的不同種類的客戶端應用軟件，請不要選擇NTLM或Kerberos。（NTLM是Microsoft專用的協議，而Kerberos是開放式的標準，但應用不廣）。同時請記住，只有當用戶已經登錄Windows域時，Kerberos和NTLM才在HTTP上可用。假如你的多數客戶是通過Internet連接的，對小用戶群，你很可能傾向于在SSL上使用基本身份驗證。對大用戶群，你可能應考慮補充使用標準身份驗證協議，該協議帶有一種基于自定義窗體或cookies的身份驗證方法。甚至你可能要考慮執行使用Microsoft護照—— 一項旨在為大型Internet環境服務的簡單登錄（single sign-on）（SSO）技術。　　身份驗證解決方案的質量，很大程度上取決于該解決方案用來識別實體對象時考慮的因素的數量。一個只依靠于用戶ID和密碼的簡單解決方案，比同時依靠于智能卡和PIN碼的解決方案在身份驗證方面的質量要低的多。前者屬于單因素身份驗證方法，而后者是雙因素身份驗證方法。對安全要求較高的.NET的解決方案，你甚至可能要考慮三因素身份驗證方法，包括用戶名、持有物件（智能卡）和生物數據（指紋）的驗證?！　∮绊懮矸蒡炞C解決方案質量的另外一個因素，就是背后的加密技術。身份驗證協議，例如Kerberos或NTLM，都比SSL客戶端基于證書的身份驗證方案輕易遭到破壞。前者使用對稱密碼，而后者使用非對稱密碼。有個例外，就是Win2K的智能卡登錄過程使用的Kerberos PKINIT。Kerberos協議的這個擴展技術同時使用對稱和非對稱密碼。（使用非對稱密碼可能需要首先打開PKI。）　　當你正為.NET基本結構設計身份驗證解決方案時，你還需要考慮憑據（credential）數據庫。憑據數據庫的設置再次取決于使用身份驗證憑據的目的（相比包含發射核導彈密碼的數據庫，公用應用軟件的密碼數據庫需要較少的保護）。在Windows環境下，活動目錄是通常存儲憑據的場所。你會選擇將所有活動目錄服務器上的憑據存放在受信任的區中，或者選擇將活動目錄服務器上的部分憑據存放在DMZ中。在后一種情況中，你或者為DMZ定義一個單獨的活動目錄森林，或者為DMZ定義一個單獨的活動目錄域，并在受信任的區使用你的活動目錄森林對它進行集成。我推薦使用前面的方法（即，在DMZ中定義獨立的活動目錄森林），這是因為它完全將受信區的帳號與DMZ的帳號屏蔽開來了。同時，該方法不需要使用防火墻上的RPC保護你的受信網絡，而答應你在SSL上使用LDAP建立內部活動目錄域和DMZ的活動目錄域之間的安全同步機制?！　∩矸蒡炞C授權　　當你正設計多等級.NET基本結構時，需要考慮的另外一項基本技術就是身份驗證授權（Authentication Delegation）。多層.NET應用軟件包括多個身份驗證層次——例如客戶端和Web服務器之間、Web服務器和COM+商務對象服務器之間、COM+商務對象服務器和數據庫服務器之間等。假如你想使用用戶身份來設置對數據庫服務器上數據的訪問控制，你所使用的身份驗證協議必須支持授權。換句話說，身份驗證協議需要有能力在機器之間轉發用戶憑證。每臺機器都使用客戶身份來對下一臺機器驗證身份?！　≌f明了授權支持是如何跟你所使用的身份驗證協議相關聯的。舉個例子，假設你正使用基本身份驗證來驗證某用戶身份，該用戶通過從他/她的瀏覽器連接到遠程服務器上的Web服務器工作。為對一臺與該Web服務器相鄰的服務器（例如Exchange 服務器）進行身份驗證，Web服務器可重復使用用戶身份。假如安裝了AD（同時Kerberos身份驗證協議可用），與Web服務器相距多個節點的服務器也可以使用該用戶身份來身份驗證。Web服務器進程可以使用Kerberos和客戶端憑證來對COM+服務器進程進行身份驗證。按此順序，COM+服務器也可以使用Kerberos和客戶身份來對Microsoft SQL服務器進程進行身份驗證（仍是在另一臺機器上）。注重，當你匿名訪問Microsoft IIS，并且答應密碼同步時，你不能授權給IUSR的servername帳號。當你使用的是基于SSL/TLS的證書身份驗證，且證書映射在AD中已經定義時，結果也是一樣。同時記住，NTLM不支持授權?！　≌f明了如何在一典型的基于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選項頁面?！　eb服務在活動目錄中必須擁有有效注冊的“Service Principal Name”（SPN，服務主要名稱）。假如Web服務的名稱不同于IIS計算機名稱，請確保使用Microsoft Windows 2000 Resource Kit中的setspn.exe實用工具來注冊自定義的SPN?！　OM+應用軟件必須支持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）上的應用軟件部署功能?！　?000年頗受關注的一個平臺安全強化主題，就是保護免受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存取

下一篇：軟件架構訓練基礎教程之使用標準