安全性概述 (ADO.NET)

保护应用程序的安全是一个持续的过程。 因为不可能预知将来会出现哪种新的攻击技术，所以开发人员永远都不能保证某一应用程序可以免受所有的攻击。 仅因为还没有人发现（或发布）系统中的安全性缺陷，也不意味着不存在或可能不存在安全性缺陷。 在项目的设计阶段，您需要对安全性进行规划，并规划如何在应用程序生存期内维护其安全。

安全性设计

在开发安全应用程序时遇到的最大问题之一是安全通常是事后的补救办法，即在项目的代码完成后才想起需要实现某些内容。 因为未考虑如何维护应用程序的安全，所以在开始阶段未注重应用程序安全性将导致所开发的应用程序不安全。

到最后关头再实现安全性将导致更多 Bug，因为软件无法承受新的制约，或必须重写才能容纳未预想到的功能。 每行修订的代码都可能引入新 Bug。 因此，您在开发过程的初始阶段就应考虑安全性，使得安全性可与新功能的开发同步进行。

威胁建模

您只有了解系统可能会受到的所有攻击，才能使系统免受这些攻击。 评估安全威胁的过程称为“威胁建模”，该过程是确定 ADO.NET 应用程序中违反安全性的可能性及后果所必要的。

威胁建模由三个高级步骤组成：了解攻击者的目的、辨别系统安全性和确定威胁。

威胁建模是一种迭代方法，用于评估应用程序中的漏洞，以找到可公开敏感数据的最危险的漏洞。 一旦确定了漏洞，您就可以按安全性对其进行排列，并创建一组按优先顺序排列的措施以应对威胁。

有关更多信息，请参见下列资源。

最小特权原则

当设计、构建及部署应用程序时，您必须假定您的应用程序将受到攻击。 通常，这些攻击来自使用运行此代码的用户的权限执行的恶意代码， 其他攻击可能源自被攻击者利用的善意代码。 在规划安全性时，始终假设将出现最糟糕的情况。

您可以使用的一种措施是：尝试使用最小特权来运行代码，在代码周围树立尽可能多的障碍。 最小特权原则指出，应在完成工作所需的最短时间内向所需的最少代码授予任何给定的特权。

创建安全应用程序的最好方法是在开始阶段不授予任何权限，然后对执行的特定任务添加最有限的权限。 相反，如果开始具有所有权限而以后拒绝个别权限，就会导致难以测试和维护的不安全应用程序，因为无意中授予过多的权限会造成完全漏洞。

有关保护应用程序的更多信息，请参见下列资源。

代码访问安全性 (CAS)

代码访问安全性 (CAS) 是帮助限制代码对受保护资源和操作的访问权限的一种机制。 在 .NET Framework 中，CAS 执行下列功能：

• 定义权限和权限集，它们表示访问各种系统资源的权限。

• 使管理员能够通过将权限集与代码组关联来配置安全策略。

• 使代码能够请求运行所必需的权限及其他一些有用的权限，并指定代码绝对不能拥有哪些权限。

• 根据代码要求的权限和安全策略允许的操作，向加载的每个程序集授予权限。

• 使代码能够要求其调用方拥有特定的权限。

• 使代码能够要求其调用方拥有数字签名，从而只允许特定组织或特定网站的调用方来调用受保护的代码。

• 通过将调用堆栈上为每个调用方授予的权限与调用方必须拥有的权限相比较，加强在运行时对代码的限制。

若要将因攻击成功而导致的损害降到最低，请为您的代码选择安全上下文，以便只向资源授予其完成工作所必需的访问权限。

有关更多信息，请参见下列资源。

数据库安全性

最小特权原则也适用于数据源。 数据库安全性一般准则包括：

• 使用最低可能的特权创建帐户。

• 不允许用户访问管理帐户，只允许运行代码。

• 不要将服务器端错误消息返回到客户端应用程序。

• 验证客户端和服务器端的所有输入。

• 使用参数化命令，避免动态 SQL 语句。

• 为您使用的数据库启用安全审核和记录，以便违反任何安全性时得到警报。

有关更多信息，请参见下列资源。

安全策略和管理

不正确管理代码访问安全性 (CAS) 策略可能会导致安全漏洞。 应用程序一旦部署，就应使用监视安全性的技术，因为将出现评估为新威胁的风险。

有关更多信息，请参见下列资源。

请参见

其他资源

保证 ADO.NET 应用程序的安全

本机代码和 .NET Framework 代码的安全性

SQL Server 安全性 (ADO.NET)