NET安全编程_第4章 安全应用程序的生命周期.pdf

44 第 4 章 安全应用程序的生命周期 本章介绍了如何将软件安全性集成到应用程序的生命周期中 并提出实际建议以帮助读 者更好理解后续章节的内容 所谓安全应用程序是指在开发时考虑了安全性的应用程序 本书坚信 只有将安全性完 全集成于应用程序的开发过程中 只有大家把安全性和系统的稳定性 性能及功能一样 重视的时候 才能实现真正有效的软件安全性 本书建议读者将本章阅读两次 读第一次可使读者对后续章节的技术内容有一个宏观的 认识 当读完整本书并对 NET 安全性有了更深入的认识之后 再读第二次 这时就可 以考虑如何改进开发进程来实现本书提供的有关安全性的建议和推荐 设计一个安全的 NET 应用程序 在实际开发一个应用程序之前都要对其进行仔细设计 这种情况几乎没有例外 对较小 的项目而言 程序员可以自己做程序设计 该设计与程序运行密切相关 也不会含有多 少高水平的技术细节 对较大的项目来说 通常是安排应用程序架构师来负责一份更精 细的程序设计 之后再把开发组件的任务分配给每个开发团队 安全性是设计过程中很重要的一部分 需要全程认真对待 一个全集成的安全策略可以 提供最强大的保护以避免应用程序遭受破坏 也可以简化将安全功能集成到程序代码中 的过程 在设计时 不能考虑集成综合性的安全模型 作为应用程序的设计者 必须理解应用程序使用平台所提供的安全功能 同理也必须理 解其他组件的功能 例如数据库和操作系统 即使设计者不参与执行应用程序 理解这 些功能也同样很重要 本书尽可能按章节介绍 NET 提供的安全功能 以便分别详细阐 45安全应用程序的生命周期 述如何在编写代码时运用安全功能 即使读者是参与最抽象级别设计的程序架构师 本 书也建议你阅读本章后续内容 在程序设计中应用安全性 首先应识别受限制资源和秘密 这里回忆下第 1章介绍的两 个概念 受限制资源是指访问权限被控制的功能性资源 秘密是指针对第三方隐藏的一 些数据 识别受限制资源 受限制资源一般分为以下三类 功能性资源 Functional resources 功能性资源是指应用程序提供的功能 例如 使用银行应用程序来批准借贷的功 能 功能性资源很容易被识别 可以使用应用程序的功能指定来定义它 外部资源 External resources 外部资源是指那些支持应用程序的资源 例如数据库 访问外部资源应该和访问功 能性资源联合使用 例如 如果用户不能通过功能性资源批准借贷 那么他也不能 被授权直接访问数据库 该联合使用证明了第1章介绍的广泛安全性这种观点的必 要性 破坏性资源 Subversion resources 破坏性资源表面看来并不是很重要 但是却可以把它和功能性资源或外部资源联合 使用以破坏应用程序或应用程序的操作平台 例如 某项破坏性资源能够向操作系 统使用的文件写入数据从而强制执行安全策略 创建应用程序的受限制资源列表是理解待定义的信任关系的基础 本书将在下节讨论该 信任关系 对于自己开发识别受限制资源的技术 本书提供如下建议 考虑自己的应用程序与其他系统交互的方式 仔细思考自己的应用程序基于其他服务的 方式 为了保护其他系统 可能会限制访问某些资源 即使它们不能被用于破坏该 应用程序 使用直觉 不要一味遵循商业的指定 作为一名架构师 应该负责设计出满足项目中 所有商业和技术目标的程序 哪怕该目标没有被详细说明 定义并遵循设计标准 通过在所有项目中应用公共设计方法 则可以创建功能性模式 其作为受限制资源可以很容易被识别 开放设计共同检查 不要独自工作 征询同事对设计的建议 每个人都有自己不同的 思维方式 在小组中共同检查应用程序的设计可以高效率地识别出破坏性资源 第 4 章46 识别信任 一旦识别出应用程序使用的受保护资源 就可以定义信任级别 用户或客户具有这些信 任级别后 才能被授权访问应用程序 信任可以被授予给一大群操作实体 包括用户 代码 外部库和不同的计算机 信任用户就意味着授权个人使用限制性资源的功能 例如 在一个银行应用程序的开发 中 可能就要允许负责借贷的官员批准别人的借贷请求 NET 支持基于角色安全的方 法 该方法定义了系统用户的类型 并考虑使用哪类资源来进行工作 本书第10章将详 细讨论 NET 基于角色的安全性 如果对代码或类库授权信任 这就意味着对包含该类的程序集授权信任 第 2章已讨论 过程序集 NET 使用程序集属性 强名称 发行商等 将其作为证据授权程序集信任 本书第 章将详细讨论证据 第 7 8 9 章将详细讨论如何使用证据 如果请求信任 实际上就是要求访问另一个应用程序的受限制资源 例如 如果用户的 应用程序需要访问数据库 则必须确保数据库服务器会接受用户电脑的通信 还要确保 用户的应用程序有权读写数据库 信任是一种关系链 它是通过应用程序基于的服务 应用程序本身及利用利用程序的服务和用户来扩展关系的 识别信任就是检查受限制资源并建立如何访问该资源的一种进程 应该检查程序基于的 服务是如何分配信任的 还应该确保应用程序设计能符合这些服务的信任需要 对于自 己开发识别信任的技术 本书提供如下建议 给执行任务分配最少的信任 定义与用户使用的任务密切相关的信任级别 确保授予限 制性资源最少的访问权力 不要为了简单而分配大型差定义的信任级别 这样会导 致较差的应用程序设计 考虑信任链的影响及其可能带来的破坏 保证应用程序不是被用来非法访问重要资源的 工具 例如 如果数据库允许应用程序对其进行读写操作 此时应用程序本身比数 据库更容易成为黑客攻击的目标 应用程序不应该以绕过数据库安全策略的方式授 予外部资源信任 考虑真实世界的信任机构 思考在真实世界中如何给程序用户分配信任 应该把实际情 况作为指定应用程序功能的基础 考虑交替信任会授权哪些操作 检查应用程序要求的信任 思考授予多文件信任级别会 带来什么影响 例如 你可能定义了一个信任级别来允许读取用户账号列表 与此 同时你又定义了另一个信任级别允许发送邮件 如果把这两个信任级别同时分配给 一个用户 你就允许把用户账号的详细信息以电子邮件的形式发送出公司 试想一 下 用户是如何将表面上没有关系的资源联系起来进而破坏你的安全策略的 47安全应用程序的生命周期 清楚地记录决定 当以文件形式记录应用程序的设计时 应该将定义安全级别的原因解 释清楚 将给用户角色或服务分配信任级别的方式记录清楚 清楚地记录这些信息 会简化开发过程 在测试应用程序时也能作为权威参考 识别秘密 识别秘密通常比识别受限制资源更简单 必须检查应用程序创建的或运行的数据类型并 决定该数据是否需要保护 本书第III部分详细讨论了使用哪些方法来保护数据 但是本 书也提供以下建议来帮助读者将应用程序的数据正确分类 考虑数据的所有者 如果你的程序要处理另一个程序提供的数据 则你的程序必须授予 数据至少和另一个程序同样的安全级别 你的应用程序不能成为访问数据的简单手 段 考虑法律义务 确保某些信息的私密性也是一项法律义务 尤其是用户的个人信息 咨 询法律建议以履行你的责任和义务 考虑数据被泄露的后果 要明白应用程序所用的数据被泄露后会产生哪些后果 并以此 评估哪些信息应该被保密 记住这一点 有时保护数据更多是为了维护其公众形象 而不是出于实际考虑 例如 泄露用户卡号给公司声誉造成的损害比给信用卡所有 者造成的损害要大得多 信用卡提供商能限制持卡者的权力 但是却没法限制糟糕 的公共效应给提供商带来的损害 正常失败 我们必须得承认一点 不可能设计出或运行无懈可击的应用程序 即使是最好的安全性 也可能被攻破 作为应用程序设计的一部分 应该时常考虑哪些操作可能会给安全性造 成缺口 继而定义相应的操作来确保应用程序正常失败 不会向攻击者暴露其他应用程 序或服务 仅仅把安全性事件写入日志文件并希望按其操作是不可取的 应用程序的设计者有责任 将其用户和客户被暴露的风险性降到最低 定义正常失败的细节因应用程序的目的和复 杂性而不同 但是至少都应该包括 如何处理安全缺口 应该采取哪些紧急措施以避免 数据和受保护资源被进一步泄露 开发安全的 NET 应用程序 程序开发员是遵循程序架构师的设计来开发程序的 开发员要编写应用程序运行的类 第 4 章48 开发员必须很好地掌握有关软件安全性的知识 尤其是开发平台提供的安全功能 这样 才能正确编写程序运行过程中的安全策略 开发员将应用程序设计中的抽象方法具体化 遵循并丰富设计中的策略 再将其转化成 准确而有活力的运行代码 本书并不建议程序开发员完全按照应用程序设计来编程 开发员有义务评估程序设计的 可行性和适宜性及设计定义的安全策略 开发员可以适当的怀疑设计 应该记住 开发 员在安全编程方面的更多知识应该和开发者的设计结合起来以改进设计 而不是将其作 为政治和文化冲突的武器来竞争 然而 也应该尊重应用程序设计的目的 除非得到架 构师的允许 否则不要轻易修改设计 对设计不必要的修改会导致运行错误 而这会 给攻击者和破坏者提供不可预见的机会 开发者通常要对其做出的运行决定负责 例如决定使用何种加密机制保秘密或决定使用 哪些安全角色 开发者在编程时喜欢使用新方法和令人激动的技术 而这些往往会给应 用程序的安全性带来隐患 使用经过反复考验的技术 使用经过广泛测试的算法和操作 能建立最好的安全性 正如后续章节的介绍 NET的安全性是由程序开发员运行 但却由系统管理员配置 只 要有可能 开发员都应该运行安全策略以简化配置 或者使用默认设置 因为它能在没 有配置的情况下提供合理的安全级别 不要希望系统安全管理员掌握足够多的安全知识 来开发应用程序 也不要希望他们有足够的时间来充分了解应用程序的复杂性 把使用 的默认设置用文件形式记录下来 并解释它们的重要性 对于安全开发应用程序 本书 提供如下建议 确保有人知道你改变了程序 独自改变程序会给应用程序带来安全漏洞 一般来说 软 件系统的组件彼此都联系密切 除非你告诉别人所做的改变 否则其他编程人员会 认为你的组件功能还和原设计一样 他们还会按照以前设计的组件功能来做出决 定 不要害怕问问题 如果在程序设计中遇到不明白的地方 应该尽快弄明白这些问题 许 多程序开发者认为这是 弱者 的象征 但是经验证明 由于不完全了解设计的细 节 或由于架构师的错误 常常会导致理解上的困惑 在开发应用程序之前一定要 确保理解所有的设计思路 适当了解开发的商业背景 你会发现理解应用程序的设计思路会比理解程序用于解决哪 些商业问题更容易一些 要记住 架构师是连接商业问题和技术解决方案的 桥 梁 有些设计从技术角度看似乎没多大意义 但这通常是商业因素所致 不要依赖未测试的安全库 开发者通常负责为运行应用程序选择第三方工具和类库 本 49安全应用程序的生命周期 书建议选择有信誉的公司的安全类库 并用自己的安全测试程序测试他们的产品 详情请见 NET 应用程序的安全性测试 使用严格的单元测试 作为应用程序的一部分 所有开发的类也应该被测试 不仅要测 试是否能实现期望功能 而且要确定意外的输入或运行也不会暴露安全缺口 在这 方面 单元测试是安全性测试的一种简化的形式 配置之前移除所有默认账号 用户通常会创建默认的用户账号或能简化单元测试的默认 信任级别 所以在测试和配置应用程序之前要确保取消或移除这些默认设置 NET 应用程序的安全性测试 正如第1章开始所描述的 安全性测试与普通应用程序的测试不一样 安全性测试员 更多的是要发现可能破坏程序安全性的方法而不是测试其配置 有效的安全性测试能大 大减少程序里的安全缺陷 还能突出程序设计里的过失 关于应用程序的安全性测试 本书提供如下建议 站在雇员的角度想问题 尽可能模拟黑客可能采取的攻击 尝试想想 一名恼怒的雇 员有可能会暗中破坏应用程序的安全性 在程序的安全性模型中 通常会授予雇员 更多信任 而这有时就会为其提供更容易的攻击路线 不只测试应用程序本身 安全性测试应该包括攻击运行应用程序的系统 例如 数据库 地址目录 邮件服务器 在 NET 运行环境中 还应该测试是否能通过攻击运行库 组件来破坏应用程序 不好的配置和安全功能会给破坏应用程序的攻击间接提供通 道 不只测试应用程序的设计 不要仅满足于通过简单测试来保证应用程序的设计可被正确 执行 这仅仅是一项基础测试 它并不能发现安全性里隐含的失败 关注攻击策略的发展趋势 关注实际的攻击方式并模拟测试 用户可能会告诉你他们遭 遇的各种攻击 你可以从其他应用程序和服务遭受的攻击中学习 随着安全性测试的价值越来越受到人们的关注 有助于开发测试过程的工具也开始出现 第一代测试工具是主要测试应用程序的配置和 NET 运行库 但是随着带来攻击的软件 越来越复杂 测试工具也得不断发展和改进 关于 NET 测试工具的概述和安全性测试 工具的一些链接 详情请访问 Microsoft NET 的网站主页 配置 NET 应用程序 系统管理员负责安装和配置应用程序 该任务包括 为 NET 基于安全角色 详见第 10 第 4 章50 章 定义的角色配置用户账号 为组成应用程序的程序集配置适当的信任级别 配置应 用程序需要的服务也很重要 例如 配置数据库和目录服务器 系统管理员有义务理解应用程序是如何被配置的 也有义务花时间思考如何为公司设定 最合适的安全配置 系统管理员希望软件发布商能为其提供一个功能强大的应用程序 而软件发布商也希望系统管理员能按照程序的说明和公司的要求来安装和配置应用程序 然而 系统管理员应该仔细考虑分配给程序集的信任级别 并保证不会分配给应用程序 过多的权限 以确保其正确运行 系统管理员还应该保证应用程序及其服务的配置不会 危及公司网络的安全 系统管理员还应该监控应用程序 寻找是否存在安全漏洞和缺陷 并及时将问题通知软 件发行商 关于运行程序时如何进行安全管理 详情请见 监控 NET 应用程序 一节 运行 NET 应用程序 一旦安装和配置了应用程序 系统管理员就可以使用公共语言运行库 CLR 来运行该 应用程序 CLR 是一种复杂的软件 本书没有详细讨论 CLR 的工作机制 本节只讨论 CLR 操作与安全性有关的两个方面 验证 Verification 是 CLR 与安全有关的第一个方面 在运行托管程序之前 CLR 会 完成验证过程 这是强制执行 NET 安全性的第一步 如果该应用程序是由强名称程序 集 详见第 2 章 组成 则这些程序集的内容将会与数字签名值进行比较检查 如果程 序集被篡改过 CLR将不会运行其代码 如果程序集的内容没有被篡改 CLR则会验证 其代码是类型安全 type safe 的 这就意味着该代码不会执行非法操作 不会直接访 问内存 也不会试图访问错误的类型成员 如果程序集所含代码是类型安全的 且程序集的内容没有被篡改 那么CLR就会验证每 个程序集的证据 evidence 并授予程序集代码相应的权限 这些程序集是基于 NET安 全策略的配置的 本书第 6 7 8 章将分别详细讨论证据 权限和安全策略 读者应该了解一个重要的事实 当应用程序一旦开始运行 CLR就会把安全运行 由开 发者执行 和配置 由系统管理员执行 二者结合起来 NET的安全性不仅仅由软件发 行商决定 它还需要用户的合作和理解 监视 NET 应用程序 要开发和配置相当安全的软件是很困难的 而要使软件避免遭受任何攻击则是不可能的 应该接受应用程序可能被破坏的现实 并制定出相应的策略 51安全应用程序的生命周期 即使完成了最后产品的配置 甚至系统管理员也完成了安全配置 用户已正在使用软件 本书建议也应该继续思考应用程序的安全性 安全性的影响会贯穿应用程序的设计和使 用 应该一直监视安全缺陷并准备好相应的策略来处理它们 抵制黑客进攻的一个有效武器就是教育 应该保证用户明白如何在应用程序中使用安全 性 帮助用户了解如何识别正在进行的攻击