Builder.com.cn - 管理&职涯 - 微软.NET开发团队回答安全问题

.NET团队的成员回答了以上除最后一个之外的其他所有主题，开发人员觉的承认某一种语言是他们最喜爱的语言会有悖于.NET平台的开放精神。以下就是这次采访的上半部分。

“.NET病毒”

Builder：我们最近看到一份报告说第一代利用.NET体系结构设计的病毒已经问世，微软再度受到了面临严峻局面却反映迟钝的批评。从代码和平台安全的角度看，.NET具有怎样的安全性？在你们的计划中是如何实现平台安全性的？

Brian LaMacchia，.NET框架平台安全开发领导：到目前为止已经出现了两种所谓的“.NET病毒”。但这两种“病毒”却恰恰都没有用到.NET体系结构而且也没有突破.NET框架的安全基础结构。在12月出现的“Donut”病毒实际上是一种相当标准的Win32病毒。最近的“Sharpei”病毒则是这么一回事：用户在其磁盘上选择下载和运行了一部分.NET框架代码。在这种情形下。用户给予这些代码在本机上运行的权限。这样，病毒其实并没有利用.NET框架的漏洞，而是在用户分派给它的自由度内运行。

那就是说，安全是我们在设计和开发.NET框架时所考虑的头号问题，这是无庸置疑的。我们从4年前就开始考虑安全问题了，而且采取了多种方法设计.NET框架的安全因素。

首先，我们采取了基于凭证的代码访问安全措施。这类技术使得系统管理员可以对其系统上运行的应用程序所能访问的资源实施有力的、小粒度的控制，而且，因为这些技术的出现，系统管理员更可以对这些措施进行设置，从而只能让那些特别秘钥签署的、来自特定URL的、接收确定哈希值的代码才能获得访问本机磁盘的权限。而其他的全部代码则运行在受到更为严格管理和权限限制的环境下，同时这些环境的设置也完全掌握在管理员手中。这些安全措施完全可以阻止“Sharpei”之类的病毒达到其目标。

然后，我们还采用了基于角色的安全机制，使开发者可以更容易地在他们的应用程序中实现认证/授权逻辑，同时在这一领域获得相当灵活的算法选择余地。

最后，我们推出了自己的加密库，这是一套很容易使用的API，提供了几乎所有的主流安全算法，比如随机数生成、加密、数字签名、哈希散列等等。这是一套在技术上相当进步的函数库，其中就包括了最新的一些先进技术，比如XML、数字签名等。

安全第一

Brian LaMacchia：长话短说，我们的安全机制是从平台最基础部分构建的，不过设计出完全正确的体系结构还只是我们工作的一半左右。早在2000年夏季，作为现在众所周知的Trustworthy Computing Initiative行动的一部分，我们请两家专业安全评估公司Foundstone和Core Security Technologies 对我们的安全体系结构及其实现进行了评估。你可以通过MSDN阅读他们发表的评估报告和有关细节。

12月的时候，按照Trustworthy Computing的下一步安排，我们对整个开发、测试和项目管理团队（大约1000人左右）进行了安全技术培训，他们用了整整一个月的时间了解和检查.NET框架以及Visual Studio .NET所存在的安全问题。我们可以自豪地宣布，这两种产品完全通过了安全检测，但是，我们的工作并没有到此为止。

软件远非完美，这就是软件产业的简单事实。我们对自己创建的、强大的安全基础结构进行了额外的测试和检查，但到今天为止，你还能在我们的服务过程中看到一些差别。我们安排了专门的队伍排着队来解决包括安全在内的任何问题，有些可能是产品引发的。我们从Nimda和红色代码病毒之类过去的经历中学习到经验教训，防范这些病毒的补丁程序早就有了，但好多系统管理员到现在都还没有安装它们。最近，我们还经由Windows Update交付了最新的补丁程序，因此用户和管理员在新的关键升级可用的时候能处于更为主动的态势。而且，我们的补丁程序是采用全面包容的形式交付的，这样，只要你下载了一个补丁程序，在此之前、从软件发布开始之后的所有问题都会得到修补。

再有，安全是我们首先考虑的问题。通过以上这些因素的联合作用——安全的平台、广泛的评估以及可靠的服务计划等——我们必能提供满足我们顾客需要和期望的产品。

即时编译

Builder：关于各种各样的编译选项及其所产生的性能表现一直存在概念上的某些误解。你能解释下JIT和安装时编译的工作原理以及每一种编译选项的性能结果吗？

Jim Miller，公共语言运行时首席项目经理：缺省情况下，在.NET框架上运行的代码都是即时（JIT）编译的。就是说，在代码运行的时候，假如编译器首次遭遇特定的方法（method），那么某一块代码将从MSIL（微软中介语言）翻译为x86机器指令。所产生的x86指令则会被存储起来供应用程序在执行期间使用。这样，如果应用程序再次调用该方法，处理器就会直接跳到对应的x86指令而无需重新编译 MSIL。一旦大多数方法都被即时编译，则JIT编译还没有被调用的不常用方法的开销几乎可以忽略不计。

在程序开始运行的时候，此时，应用程序大多数或者所有的方法都是首次提交给JIT编译器，应用程序的性能自然会受到一定程度的冲击。为此，我们又为代码提供了可选择的pre-JIT （也称为本机映像生成器：NGEN）。这种技术将在运行时之前把MSIL翻译为x86指令，从而有效地避免了程序启动的延迟现象。简而言之，如果程序的启动时间成为一个问题，那么你不妨考虑对程序代码进行pre-JIT编译。