摘要: 在控制面板中启用 IIS 时，发现各项功能的控制粒度很细，打开首页，只显示这样一个图片，不过目前 IIS7 的管理工具似乎还没有包含在 Vista 中。 这几天领教了 Vista 中的 UAC 和 Internet Explorer Protocted Mode 的厉害，不过，我对一部分最终用户能不能很好地接受这个Fetature信心不足，尤其是开启/关闭 UAC 的时候，需要重启计算机。 在 Internet Explorer Protocted Mode 时使用极点五笔，一直报错，不让访问安装目录下的码表文件（注：只在 IE 中报错，在其他应用程序中则不受影响），不得已，只好设置 Protocted 为 Off，现在我还没有找到其他好的解决办法，在网上看到一些 Post ，好象其他的一些输入法也有类似问题。...[阅读全文]

摘要:1、看起来参会人员似乎和去年差不多，可房间却十分紧张，最后挤在四人间，而且距离会场较远，TechED 渐有成为唯一的微软年度盛会之势，PDC 已经两三年不见了； 2、有幸见到一位厉害人物，VB 产品组的总经理潘正磊，从 Access 1.0 做起一直到现在 14 年，参与主持开发的产品很多，虽然自己现在 VB6, VB.NET 基本上用的 少了，但受到其个人魅力吸引，两堂课都听了，很受感慨，要是在中国，能找到这样一位14年编写代码，做产品规划和管理，还能在课上大讲 Debug 技巧与 Tricks/Tips 的人吗，一行一行调试代码的人吗？ 3、Vista/Longhorn Server 的远程显示协议（RDP） 到 V6.0 ，支持 Gateway ，更安全（类似于 Outlook 的 RPC Over HTTPS），支持NAP（网络访问保护），可以直接支持远程应用程序，这个特性很 Cool，不过似乎很象 Citrix 的东西； 4、SharePoint 中的工作流基于 WF（为什么不叫 WWF 了？这和WPF、WCF不匹配呀）真不错，Kaneboy 演示的例子也非常好，看来也是精心准备的，可惜 kaneboy 问的问题没太有把握，没敢举手，没有拿到礼物，回头买一本支持一下，自己翻译过书，也知道写书、翻译书挺累的，要尊重作者劳动和知识 产权，呵呵，顺便夸奖一下 Kaneboy 的美女同事 TingLi ，技术、演讲能力都不错，同 Team 的其他成员都不错。回头再做开发的时候，要好好考虑一下能不能用 Infopath + SPS 2007 搞定，这样能避免大量无聊的代码了，开发生产力第一； 5、最近是国内各大银行网上银行的多事之秋，传统的“用户名+密码”的安全弱点已无法承担此重任，使用数字证书也仍然在端点上存在一些问题，Vista 的 CardSpace（InfoCard）技术来得正是时候，不过我估计给银行的决策人员介绍是可以，要用的话，估计还得段时间，要使用它，还是需要一些魄力与技术洞察力的； 6、今年听了一些 MOM 的课，东西是好东西，可如何说服领导花钱购买这个东西，提高管理水平，这似乎是个问题； 7、今年的动手试验室不错，但时间还是感觉紧张，脚本也没有翻译成中文，绝大多数人都做不完，不过能开放16个小时也不错，晚饭后还做了两个 Biztalk 2006 的试验，可惜没有带大硬盘，把这些虚拟机和资料 Copy 回家自己慢慢看； 8、今年的赞助商似乎不如去年，缺少去年 AMD 的那种气势； 9、今年的 MVP 活动感觉不如往年，没有很好的机会聚在一起好好聊聊，缺乏交流致使大家都不怎么互相认识，感觉比较陌生，而且把自己喜欢的一张 MVP 海报拉在房间里了，依旧感谢 MVP Lead 为我们申请的门票； 10、日程安排得挺紧张，有点累，得好好休息一下了，刚好凑够10条，呵呵。...[阅读全文]

摘要:在 ASP.NET 2.0 的 Web.sitemap 文件中，siteMapNode 有个属性 roles ，乍一看，就象是设置此结点允许哪些角色可以访问/显示，如： <siteMapNode url="~/Admin/Default.aspx" title="系统管理" description="" roles="Manager"> 好象就表示属于 Manager 角色的用户可以访问/显示。但我在使用的时候却发现，无论当前用户是否登录，是否属于 Manager 角色，这个菜单项都能正常显示，且能正常进入，那这个 roles 属性的意义到底在哪里呢？   后来查了一下才发现，要想达到我说的效果（即根据用户的角色自动显示/隐藏菜单项），必须进行如下两个步骤： 1） Web.Config 的 SiteMap 中启用安全修整，完成后如下所示： <siteMap defaultProvider="default">  <providers>    <clear/>    <add name="default" type="System.Web.XmlSiteMapProvider" siteMapFile="web.sitemap" securityTrimmingEnabled="true" />  </providers></siteMap> 2）利用 Web.config 来实现文件或URL授权，即对 Admin 目录下的设置访问规则（可以利用 VS 2005 中的 ASP.NET 配置来实现），完成后如下所示： <system.web>  <authorization>    <allow roles="Manager" />    <deny users="*" />  </authorization></system.web> 现在菜单终于可以自动根据用户的角色是否属于 Manager 来显示/隐藏了，但问题是，这好象完全是 Web.config 来设置的，和 siteMapNode 中的 roles 一点关系也没有，那这么 roles 的意义在哪里呢？ 从 MSDN 中找出这么一段话：“当用户属于 roles 属性中列出的某一角色时，使用该属性后，ASP.NET 可避开与 siteMapNode 关联的 URL 授权限制。”，可是如果我想避开限制的话，我就根本不用在 Web.config 中设置。既然在 Web.config 中设置了限制，却又在这里用 roles 绕开限制，是不是吃饱没事干了？ 现在唯一能为这个 roles 找到一个很小的用处就是，如果结点上不指定 url 属性，可以利用此属性（roles="*"）来强制显示此结点，以便能够显示下一级结点，如： <siteMapNode url="" title="系统管理" description="" roles="*">    <siteMapNode url="~/Admin/Member_List.aspx" title="用户管理" description=""/>    <siteMapNode url="~/Admin/Role_List.aspx" title="角色配置"......[阅读全文]

摘要:一、授权管理概述 一般在应用程序中，比较理想、完整的授权模式就是基于角色的授权（Role Based Access Control-RBAC），它的主要目标是实现了用户与安全操作的分离，而在中间加入了角色的隔离层，从而实现了灵活性和可扩展性，具体来说，主要是这种方式： 在编写程序的时候，定义出程序的功能（或称为安全操作，如 AddBook, ModifyBook ...） 在应用程序部署的时候，按照业务安全策略的要求，定义角色（如 BookManager），并定义角色与功能的对应关系 在应用程序运行期，定义可以使用系统的用户（如张三、李四），然后定义用户与角色的关系 这样通过“三个实体，两个对应”，就能找到用户和功能的关系（即用户能否执行此功能）。 二、ASP.NET 2.0 中的授权管理功能 ASP.NET 2.0中，提供了三种授权管理的提供者，分别为：AspNetSqlRoleProvider、AuthorizationStoreRoleProvider、AspNetWindowsTokenRoleProvider。 默认 AspNetSqlRoleProvider 只能提供角色与用户的实体及其对应关系，缺乏功能层次的定义和关系，所以仅能适用于有限场合，如基于 URL 的授权，或者在程序中手动使用 Roles API（Roles.IsUserInRole）来判断当前用户是否具有授权，但是这种方式的前提是角色是 Hard Code（硬编码的），以后如果角色所允许的功能发生了变化，只能通过修改程序来实现。 再来看看 Windows 2003 中附带的授权管理器（Authorization Manager，以下简称 AzMan），不可否认，它的设计比较完整地体现了 RBAC的思想，即首先定义操作，然后把操作归类形成任务（大任务也可以包括子任务），可以定义角色，然后在角色中定义其可以执行的任务或操作（大角色也可以包含小角色），最后可以应用程序中分配用户、建立角色与用户的对应关系，同时，AzMan 还提供业务规则检查的功能，即可以在任务级别定义脚本，对是否授权进行进一步的细粒度的检查，表面上看，还是比较圆满的。 但是 AzMan 的一个重大限制就是只支持 Windows 用户，它要求用户的标识为 SID（如S-1-5-21-XXXX-XXX）的格式。虽然我们可以使用 AzMan 的 API ，如 InitializeClientContextFromStringSid 来构造一个虚拟的 SID （例如，在我们的应用程序中，我们用户的 ID 为一个自增量的整数 Y，那就可以虚拟成 S-1-5-21-Y的方式）这样我们就可以利用 AzMan API 来绕开只允许Windows 用户的限制，但这些工作全部要手工完成，纯体力活，得不偿失。 本来以为 ASP.NET 2.0 的AuthorizationStoreRoleProvider 做为默认的三种 RoleProvider 之一，能为我们提供这些方面的便利功能，但在使用之后才发现，限制依然存在，实用性仍然不够： 在定义角色时，它会把角色定义在 AzMan的“角色分配”结点上，而不是“角色定义”结点上，有点奇怪 如果使用 AspNetSqlMembershipProvider ，那么在为用户分配角色时，就会引发“帐户名与安全标识间无任何映射完成”的错误，这可以看出来 AzMan 依然是使用 Windows 用户，这一个限制很是致命，也就是说 AspNetSqlMembershipProvider 和 AuthorizationStoreRoleProvider 是不能共用的。 如果能够把 AspNetSqlMembershipProvider 中用户的 MemberId （GUID类型，格式为“XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX”）转换成 SID （S-R-I-S-S）还有可能通过 AzMan API 来利用AzMan ，但这不是通过 AuthorizationStoreRoleProvider 来进行的，而且目前我也没有找到好的、能够双向转换的方法。 三、一种实用的授权管理机制设想 目前临时想到一种即能完整实现 RBAC，又能利用 RoleProvider 的解决办法是： 利用 AspNetSqlRoleProvider 来管理 Role、定义 Role 与AspNetSqlMembershipProvider 中用户之间的关系 新增一自定义XML文件，在其中定义任务/操作列表，在编写程序时，可以在类或方法的属性中指定操作名称 同时在上述XML文件中定义 Role 与操作的对应（包含）关系 在程序中利用公用程序来检查权限，这无需写死（Hard Code）任何东西，因为是直接从当前类/方法中取出操作名称，再直接获得当前用户名，再检查第 2、3步的XML 文件文件即可。...[阅读全文]

摘要:非常喜欢Visaul Studio 2005 中的代码段，大大节省了一些无聊的、没有技术含量的代码编写工作，如实体类的属性设置等。 Visual Studio 2005 中的 VB.NET 的代码段比 Visual C# 的多出不少，是不是吸引开发人员？ 我们可以修改系统中现有的 snippet 文件（C:\Program Files\Microsoft Visual Studio 8\VC#\Snippets\2052\Visual C#目录），来增加自己常用的 snippet。 网上（http://www.gotcodesnippets.net/）也有不少别人编写的 snippet ，可以按需取用。 要想共享或发布 snippet，最好做成Visual Studio 支持的格式 vsi ，其实是就是一个 更改了后缀名的 zip 文件，里面包含一个 XML 描述文件、一个或多个 snippet 文件（可以从上面网站中获得一个 vsi 文件来参考如何制作过程）。  在 Visual Studio 2005 中，插入代码段的快捷键是 Ctrl K + Ctrl X ，代码段管理器的快捷窗口是 Ctrl K + Ctrl B。 这里提供一个比较好用的 Public Property 的 Snippet ，是对 http://www.gotcodesnippets.net 上拿到 Public Property 稍加修改之后形成的东西，这个我最常用 :) 。<?xml version="1.0" encoding="utf-8"?> <CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet"> <CodeSnippet Format="1.0.0"> <Header> <Title>Public Property</Title> ......[阅读全文]

摘要:最近在多处看到仍有人说 Windows 平台的安全等级是 C2 级，这里纠正一下。 正式获得 C2 级安全等级认证是 Windows NT 4.0 ，它是基于美国可信计算机系统评测标准 TCSEC（桔皮书，它把系统安全级别划分为 D、C1、C2、B1、B2、B3 和A级）上获得的，现在没有 TCSEC了，大家都遵循 CC（通用准则，它把系统划分为 EAL 1-7 级）了，Windows 2000、Windows XP SP2 和 Windows 2003 在 CC 上都是达到 EAL4+ 级。 TCSEC和CC 的考察维度和要求不太一样，因此两个标准的级别可比性不大，但有些人也对此对过比较，认为在保证性方面，CC 的 EAL4 相当于 TCSEC 的 B1，EAL4+ 比 EAL4 高，相当于原有的 B1 - B2 之间。...[阅读全文]

摘要: function act1(no) { if(document.all.item("y"+no).style.display=="") document.all.item("y"+no).style.display="none"; else document.all.item("y"+no).style.display=""; } 1、在 Windows 或 AD 中批量增加用户 使用方法，新建一 users.csv，字段格式必须按如下顺序，且不能为空： 登录名, 姓名, 密码,  描述；然后将脚本与 CSV 文件存储至同一目录，以管理员/域管理员运行脚本即可。代码>>  (单击显示/隐藏) '// Name: BulkAddUser '// Purpose: 从 CSV 文件中批量生成 Active Directory 用户 '// 注意: '// 1. 源文件必须使用逗号分割 '// 2. 字段必须按如下顺序，且不能为空： 登录名, 姓名, 密码, 描述 '// 3. 只能由域管理员才能运行此程序 Option Explicit Dim oFSO, oTF, objRootDSE, objContainer, i Dim aLine, sLine, sLogon, sPass Dim sLoginName, sDisplayName, sDescription '// 用户批量文件 Const InpFile = "users.csv" Const ForReading = 1 Set oFSO = CreateObject("Scripting.FileSystemObject") Set oTF = oFSO.OpenTextFile(InpFile, ForReading, True) Set objRootDSE = GetObject("LDAP://rootDSE") Set objContainer = GetObject("LDAP://cn=Users," & objRootDSE.Get("defaultNamingContext")) i = 1 Do While oTF.AtEndOfStream <> True sLine = oTF.ReadLine aLine = Split(sLine,......[阅读全文]

摘要: function act(no) { if(document.all.item("x"+no).style.display=="") document.all.item("x"+no).style.display="none"; else document.all.item("x"+no).style.display=""; } 前几天，思归提到数据库安全是个大问题，我深有同感，感觉现在大家在外围、应用安全上做的工作比较多，往往忽视了数据库的保护，而这部内容恰恰是最关键的信息资产，正好本人与同事最近刚翻译完成了一本这方面的著作，《数据库加密——最后的防线》近期将由电子工业出版社出版，本书中详细介绍了如何对数据库的数据进行加密，同时给出了 Java 样例代码。 译序节选>>   (单击显示/隐藏) 安全性本身涉及的内容和范围非常广泛，从整体层次上来说，包括安全策略、安全管理、物理安全、网络安全、主机安全、应用安全、数据安全等许多领域，针对这些主题，业界已经提供了大量成熟的解决方案和最佳实践，从微观上来说，安全基础技术——密码学的发展也相当成熟。通过在以上各个层次中合理地使用密码技术，能够有效地满足绝大多数安全需求，关于这些内容的安全资料和书籍非常丰富，但是唯一令人遗憾的是，关于密码学在数据库中的应用这个领域，即数据库加密，却被很多安全专家和技术人员所忽视，很少有人去研究，因此也鲜有相关著作，其主要原因是大家一般寄希望于数据库管理系统来保护数据的安全性，但是在实际应用中，数据库管理系统所能提供的保护作用是有限的。 大多数情况下，应用系统中最有价值的资产就是商业数据，尤其对一些特定行业，如金融行业来说，数据的机密机至关重要，甚至事关企业的命运和发展。例如去年美国付款信息处理公司CardSystems遭受黑客入侵，造成了美国史上最大一起的数据泄露事件，此次泄密事件波及的信用卡用户多达4000万人，严重影响了全世界范围的数千万客户，甚至包括中国的数千名用户，这使得银行和信用卡公司不得不为所有客户重新换发所有信用卡，这不但带来了巨大的业务损失，更重要的是，对公司的声誉、客户的信心带来了沉重的打击。 由此可以看出，数据安全在整个系统安全中非常重要的一个环节，虽然应用程序和数据库管理系统可以为数据提供相当程度的安全保证，但是要看到，由于数据在物理上一般存储在单独的服务器上，攻击者可以很容易破解或绕过应用程序而直接访问数据库，另外，由于数据库管理系统使用不当或者攻击者绕过数据库管理系统来直接访问数据库所对应的原始文件，数据库管理系统所提供的安全保护也失效了，除此之外，那些合法的用户，如数据库管理员、应用开发人员都有可能轻易读取数据库中的内容，从而破坏数据的机密性。因此，如果不在数据库内部实施额外的安全措施，如数据库加密，就难以完全保证数据的安全性。 考虑到数据库系统的复杂性，因此保护数据库并对其进行加密也是一个非常错踪复杂的问题，如密码算法和模式的选择、密钥的管理等，如何才能有效地入手呢？《数据库加密——最后的防线》，这本来自业界领先的安全公司 Symantec IT应用与数据库安全项目主管的著作，将带给你这些问题的答案。 在本书中，作者Kevin Kenan全面地介绍了与数据库加密这个主题有关的方方面面的问题。包括了解保护数据的必要性，如何构建一个真正的数据库威胁模型，加强数据库安全的需求分析、对数据进行分类、如何编写与密码系统安全交互的数据库应用程序、避免常见的威胁数据库安全的漏洞和问题，以及如何在测试、部署、保护及终止过程中保护数据库应用的安全性等。 本书分为四大部分，第一部分首先介绍了安全性的基本含义及其在数据库中的具体体现，随后讲述了密码学和数据库的一些基础知识和密码学在数据库中的应用。在第二部分中，介绍了密码系统的基础架构和密码系统中的各个组件，如密钥库、密钥管理器、密码提供者、密码引擎等。 第三部分介绍了密码系统的项目管理，描述了一个项目开发生命周期的各个阶段应該注意的安全问题，如在需求阶段进行需求定义、确定策略、标准及算法，在设计阶段，提到了应該遵循的安全设计指南及最佳实践，并介绍了威胁建模及安全模式方面的内容。在开发阶段，介绍了应該注意的最主要的安全开发实践；在测试阶段，主要介绍了安全功能测试和穿透测试，前者是从正面的角度测试各种功能是否存在，而后者是从攻击者的角度来测试系统安全措施的有效性如何，是否存在任何漏洞。最后，介绍了应用程序在部署、运行及终止阶段应該注意的安全问题，这是一部分很容易被忽视的重要内容。 在第四部分中，作者针对之前描述的各种理论、技术与实践，给出了一个数据库加密系统的Java实现，这是本书中非常有价值的一部分内容，通过这部分代码，读者可以更准确、更深入地了解本书中的内容，最后，给出了这个示例系统的运行演示。这些代码可以在少量修改后，就可以应用到实际的项目中去。这部分代码可以从作者的网站（http://www.kevinkenan.com）上下载，其中包括了相关的使用说明，包括如何建立初始数据库等。 目录节选>>   (单击显示/隐藏) 第一部分：数据库安全1、数据库安全问题1.1、数据库面临的攻击1.2、保护数据库的外部需求2、使用加密保护数据库2.1、数据库知识的快速复习2.2、密码学是什么2.3、密码学应用2.4、加密的风险2.5、加密面临的攻击2.6、混淆2.7、传输加密 第二部分：加密基础设施3、加密基础设施概述3.1、应用程序架构3.2、加密系统加构3.3、加密密钥4、加密引擎和算法4.1、本地引擎4.2、专用引擎4.3、加密算法 5、密钥存储库、清单和管理组件5.1、密钥存储库5.2、密钥清单5.3、密钥管理组件 6、加密提供者和使用者6.1、提供者6.2、使用者 第三部分：加密项目7、加密项目的管理7.1、安全意识7.2、客户参与7.3、项目范围7.4、项目角色 8、增强需求的安全性8.1、安全需求、策略和标准8.2、一般需求8.3、需求复查8.4、确定加密标准8.5、数据分类 9、提高设计的安全性9.1、数据流图9.2、设计指南9.3、威胁建模9.4、安全模式9.5、设计密码系统 10、安全开发10.1、安全开发指南 11、测试11.1、安全功能测试11.2、穿透测试 12、部署、保护与终止12.1、部署12.2、保护12.3、终止 第四部分：示例代码13、示例说明13.1、工具和通用服务13.2、引擎与密钥库示例 14、密钥库14.1、本地密钥14.2、本地密钥的存储14.3、访问本地密钥15、清单15.1、密钥别名 16、密钥管理程序16.1、密钥工具-KeyTool 17、引擎17.1、本地引擎 18、票据与提供者18.1、加密请求与解密结果18.2、票据18.3、提供者 19、使用者19.1、客户信息19.2、信用卡信息19.3、客户管理对象 20、异常 21、示例系统运行演示21.1、设置密钥21.2、操作客户信息21.3、替换密钥21.4、替换加密密钥的密钥 查看：Amazon 原版信息...[阅读全文]

摘要:经常借用别人公司的一台托管的服务器上传下载些资料，顺便也帮人盯着服务器的配置与安全，前两天发现，系统盘 10G 硬盘空间没剩多少了，进去一看，原来 IIS 的日志文件（%windir%\system32\logfiles）下有5－6个G的日志文件，每天的日志约有 30-40M，于是把这些日志文件备份出来，压缩存储了一下，立刻节省了大量磁盘空间出来。 这个网站的访问里并不大，但日志文件为什么这么大呢，打开一看，IIS 的日志记录是很详细完整，但是仔细一看，好多行信息都是 jpg 和 gif ，这可能由于这台服务器是公司/产品宣传的缘故，所以图像文件较多，因此当访问一个页面时，会记录 10-20 条日志信息，从日志的真正用处来看，这些多余的图像文件的访问日志并不需要，而且，这么多的日志信息显然消耗了服务器的计算、IO、存储资源，影响高并发时的性能。 于是想在 IIS 的日志里对记录的 URI 资源类型做一下限制，很遗憾，没有发现这样的选项，在 Google 上似乎也没有找到替代的做法，这样看来，这好象是 IIS 日志记录功能的一个不足之处。 更新：感谢思归提供的解决办法，我把 Images 目录的日志记录取消了之后，日志文件在大小见下图： 另外再次极力推荐一下 IIS 的 gzip 功能，最近一直在研究其对性能和带宽的影响，应该来说，对于绝大多数互联网上的服务器来说，CPU 的资源比带宽资源的利用率更低，因此应该利用这些闲置的 CPU 资源来压缩页面，降低带宽点用，提高响应速度，而且，对于静态内容来说，这种压缩可以生成临时文件，避免每次访问都对资源进行压缩，因此对 CPU 资源的影响也是非常小的。对于大型企业来说，要在集中位置部署一个 B/S 的系统，那么利用 gzip 能大大节省租用运营商通讯线路带来的成本（利用 Internet Security and Accelerator 提供的 HTTP 压缩和缓存功能，也可以达到同样的目的） 在 port80software 这个网站上，提供了一在线测试工具，可能对你的网站进行测试，以确定其是否提供 gzip 压缩以及压缩比重、传输速度的提升等。...[阅读全文]