注册
登录
| 关键词： 8226 应用程序 数据库 帐户 身份 验证 Server 数据 标识 SQL |
来自：MSDN 发布日期： 10/8/2004 浏览全部的安全性指导主题 Microsoft Corporation 在本章中 数据存储，例如 Microsoft_ SQL Server™ 2000，在大多数分布式Web应用程序中起着至关重要的作用。数据存储可以包含各种类型的数据，包括用户应用程序参数、个人私密数据和医疗记录、审核以及安全日志，甚至还包括用户访问应用程序所需的凭据。很明显，这些数据都应该受到保护 — 不论是在存储期间还是在读/写的操作过程中 — 都要确保这些数据只能被拥有相应权限的用户访问。 本章描述了与访问数据存储相关的关键安全性问题的解决方案，并提供了从分布式 Web 应用程序中访问数据的建议。本章主要专注于 SQL Server 2000，但其中的许多主题在其它数据存储中也是同样适用的。 目标 学习本章： • 创建安全的数据访问组件。 • 使用 Windows 身份验证或 SQL Server 身份验证从 ASP.NET 连接到 SQL Server。 • 选择适合您应用程序的 SQL Server 2000 的授权机制。 • 使用 SSL 或 IPSec以保护数据在客户端应用程序和数据源之间传送过程中的安全。 • 创建在 SQL Server 2000 中使用的拥有最少权限的数据库帐户。 • 安全地存储数据库连接字符串和用户凭据。 • 使用密码哈希和 salt 值将用于身份验证的用户凭据安全地存储到数据库中。 • 防止 SQL 数据库受到 SQL注入式攻击。 • 在 SQL Server 2000 上启动审核机制。 适用于： 本章适用于下列产品和技术： • Microsoft_ Windows_ XP 或 Windows 2000 Server（带有Service Pack 3）及其后的操作系统 • .NET Framework 1.0 版本（带有Service Pack 2）及其后的版本 • Microsoft Visual C# .NET 开发工具 • SQL Server 2000（带有Service Pack 2）及其后的版本 如何使用本章 要从本章中得到最大的收获： • 您必须拥有使用 Visual C# .NET进行编程的经验。 • 您必须拥有开发和配置 ASP.NET Web 应用程序的经验。 • 您必须拥有配置 SQL Server 2000 安全性的经验。 • 您必须拥有使用 Windows 管理工具配置 Windows 安全性和创建用户帐户的经验。 • 阅读文章“Introduction to Building Secure ASP.NET Applications”，该文详细说明了身份验证、授权以及分布式 Web 应用程序中的安全通信的重要性。 • 阅读文章“Security Model for ASP.NET Applications”，该文概述了用于创建分布式 ASP.NET Web 应用程序的体系结构和技术，并且着重指出了身份验证、授权以及安全通信在此体系结构中所处的位置。 • 阅读文章“Authentication and Authorization”，该文提供了有关模拟、受信任子系统和 SQL Server 2000 角色的信息，这些主题都会在本章中进一步讨论。 • 阅读文章“Communication Security”，该文介绍了 SSL 和 IPSec，您可以使用它们来保护数据存储和客户应用程序之间的通信信道。 • 阅读文章“ASP.NET Security”，该文涉及深入的与 ASP.NET 相关的安全问题。尤其是进程标识、调用方标识和模拟的问题，这些问题影响了您的 ASP.NET 应用程序进行数据存储的身份验证时可用的选项。 • 请阅读下列文章，这些文章介绍了如何实现在本章中提到的许多技巧： • “How To Create a Custom Account to run ASP.NET” • “How To Use IPSec to Provide Secure Communication Between Two Servers” • “How To Use SSL to Secure Communication with SQL Server 2000” • “How To Create a DPAPI Library” • “How To Use DPAPI (Machine Store) from ASP.NET” • “How To Use DPAPI (User Store) from ASP.NET with Enterprise Services” • “How To Store an Encrypted Connection String in the Registry” • “How To Use Forms Authentication with SQL Server 2000” 本页内容 介绍数据访问安全性 身份验证 授权 安全通信 用最少的权限连接 创建具有最少权限的数据库帐户 安全存储数据库连接字符串 为数据库验证用户身份 SQL 注入式攻击 审核 SQL Server 的进程标识 小结 介绍数据访问安全性 图 1 显示与数据访问相关的重要安全性问题。 图 1 重要的数据访问安全性问题 下面总结图 1 中显示的重要问题（本章的其余部分将详细讨论这些问题）： • 安全存储数据库连接字符串。如果您的应用程序使用 SQL 身份验证连接到 SQL Server，或者连接到需要显式登录凭据的非 Microsoft 数据库，则这一点尤其重要。在这些情况中，连接字符串包含明文形式用户名和密码。 • 使用正确的标识来访问数据库。利用调用进程的进程标识、一个或多个服务标识或者原调用方的标识（使用模拟/委派）可以执行数据访问。选择什么样的标识由数据访问模型确定–受信任的子系统或模拟/委派。 • 保护通过网络传递的数据的安全。例如，保护登录凭据以及传入和传出 SQL Server 的机密数据。 注 仅在您使用 SQL 身份验证而非 Windows 身份验证的网络上公开登录凭据。 SQL Server 2000 利用服务器证书支持 SSL。IPSec 还可以用于对客户端计算机（例如 Web 或应用程序服务器）和数据库服务器之间的通信进行加密。 • 对数据库调用方进行身份验证。SQL Server 支持 Windows 身份验证（利用 NTLM 或 Kerberos）和 SQL 身份验证（利用 SQL Server 内置的身份验证机制）。 • 向数据库调用方授权。权限与单独的数据库对象关联，也可以与用户、组或角色关联。 SQL Server 网关守卫 图 2 重点说明 SQL 服务器数据访问的重要网关守卫。 图 2. SQL Server 网关守卫 重要的网关守卫包括： • 选择的用于保存数据库连接字符串的数据存储。 • SQL Server 登录（由在连接字符串中指定的服务器名确定）。 • 数据库用户（SQL Server 登录所映射到的数据库中的用户上下文）及其相关的数据库角色。 • 与单独的数据库对象关联的权限。 权限可分配给用户、组或角色。 受信任的子系统与模拟/委派 数据库访问权限的粒度是一个需要考虑的关键因素。您必须考虑您是需要对数据库进行用户级授权（这需要模拟/委派模型），还是可以在应用程序中间层使用应用程序角色逻辑向用户授权。这就是受信任的子系统模型。 如果数据库要求用户级授权，那么您需要模拟原调用方。尽管这种模拟/委派模型受支持，但是建议您使用受信任的子系统模型；在该模型中，在 IIS/ASP.NET 关口对原调用方进行检查，将它映射到某个角色，然后根据角色成员身份向它授权。然后，在应用程序或角色级别上使用服务帐户，或者使用应用程序的进程标识（比如 ASPNET 帐户），向应用程序的系统资源授权。 图 3 显示这两个模型。 图 3 用于数据库访问的受信任的子系统模型和模拟/委派模型 当连接 SQL Server 进行数据访问时，还有许多应当考虑的重要因素。下面总结这些因素（后面各节中将详细阐述）： • 应当使用什么类型的身份验证?虽然 Windows 身份验证提供增强的安全功能，但是防火墙和非信任域可能会迫使您使用 SQL 身份验证。如果情况果真如此，您应当确保应用程序尽可能安全地使用 SQL 身份验证，这将在本章内下文中的“SQL 身份验证”一节中介绍。 • 单用户角色与多用户角色。根据应用程序的用户，您的应用程序是需要单独使用一个在数据库内拥有一组固定权限的帐户访问 SQL，还是需要多个（基于角色的）帐户? • 调用方标识。数据库需要通过调用上下文来接收原调用方的标识才能执行授权或审核，还是您可以在应用程序级别使用一个或多个受信任的连接来传递原调用方标识吗？ 操作系统要传递原调用方的标识，它需要在中间层使用模拟/委派模型。这会大大降低连接池的效力。虽然连接池仍处于启用状态，但是它会生成许多小池（分别为每个安全上下文），几乎不重用任何连接。 • 您正在向数据库服务器发送或从该服务器发出机密数据吗?虽然 Windows 身份验证可以让您不必在网络上向数据库传递用户凭据，但是，如果您的应用程序数据属于机密数据（比如，雇员详细资料和工资表数据），则应当使用 IPSec 或 SSL 予以保护。 返回页首 身份验证 本节介绍在连接到 SQL Server 前您应当如何对 SQL Server 的客户端进行身份验证以及应当如何在客户端应用程序中选择用于数据库访问的标识。 Windows 身份验证 Windows 身份验证比 SQL 身份验证更安全，原因是前者有以下优点： • 为您管理凭据，并且不在网络上传递凭据。 • 使您避免在连接字符串中嵌入用户名和密码。 • 通过设置密码失效期限、最小长度和在多次无效登录请求后锁定帐户，登录安全性得以提高。这减轻了字典攻击带来的威胁。 在以下方案中应使用 Windows 身份验证： • 您使用了受信任的子系统模型并且要使用单个固定标识连接到 SQL Server。如果您从 ASP.NET 进行连接，这会假定 Web 应用程序配置中没有设置模拟。 在这一方案中，请使用 ASP.NET 进程标识或服务组件标识（从用来运行 Enterprise Services 服务器应用程序的帐户中获得）。 • 您打算利用委派来委派原调用方的安全上下文（并准备通过放弃数据库连接池来牺牲应用程序的可伸缩性）。 当您使用 Windows 身份验证来连接到 SQL Server 时，请考虑以下关键点： • 使用 ASP.NET 进程帐户的最少权限原则。不要通过将“充当操作系统的一部分”这一权限授予 ASP.NET 进程帐户来启用 LogonUser API 调用。 • 确定哪些代码需要更多权限，然后将这些代码放到在进程外 Enterprise Services 应用程序中运行的服务组件内。 更多信息 有关从 ASP.NET 访问网络资源以及选择和配置正确的帐户以运行 ASP.NET 的更多信息，请参见文章：“ASP.NET 安全性”。 使用 Windows 身份验证 使用 Windows 身份验证从 ASP.NET 应用程序（或 Web 服务，或者 ASP.NET 承载的远程组件）连接到 SQL Server 时，您可以从以下方法中选择： • 使用 ASP.NET 进程标识。 • 使用 ASP.NET 中的固定标识。 • 使用服务组件。 • 使用 LogonUser API 并模拟特定标识。 • 使用原调用方的标识。 • 使用匿名 Internet 用户帐户。 建议 建议通过在 Web 服务器上将密码更改为某个已知值来配置本地 ASP.NET 进程标识，然后在数据库服务器上通过创建具有相同用户名和密码的本地用户创建镜像帐户。下面详细介绍这一方法以及其他方法。 使用 ASP.NET 进程标识 如果您直接从 ASP.NET 应用程序（或 Web 服务，或者 ASP.NET 承载的远程组件）连接到 SQL Server 时，请使用 ASP.NET 进程标识。这是一种常用方法，并且该应用程序定义了信任界线，也就是说，数据库信任 ASP.NET 帐户访问数据库对象。 您有三个选项： • 使用镜像的 ASPNET 本地帐户。 • 使用镜像的自定义本地帐户。 • 使用自定义的域帐户。 使用镜像的 ASPNET 本地帐户 这是一种最简单的方式，一般在您拥有目标数据库（并且可以控制本地数据库服务器帐户的管理）时使用。如果选择此方法，您应使用 ASPNET 最少权限本地帐户来运行 ASPNET，然后在数据库服务器上创建一个重复帐户。 注 这种方法还有一个优点是，它可以跨非信任域和通过防火墙发挥作用。防火墙打开的端口数可能不足以支持 Windows 身份验证。 使用镜像的自定义本地帐户 此方法与上一方法基本相同，不过使用此方法时您不使用默认的 ASPNET 帐户。这意味着两件事： • 您需要创建一个自定义的、拥有适当权限和特权的本地帐户。 有关详细信息，请参见 “How To Create a Custom Account to Run ASP.NET”。 • 您不再使用 .NET Framework 安装进程创建的默认帐户。公司的某项制度可能不允许使用默认安装帐户。这有可能提高应用程序的安全门槛。 有关详细信息，请参见 Sans Top 20：“G2–没有密码或密码隐密性最弱的帐户” (http://www.sans.org/top20.htm)。 使用自定义的域帐户 < |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
