安全概述

保护应用程序是一个持续的过程。 开发人员永远不会保证应用程序免受所有攻击的安全，因为无法预测新技术将带来什么样的未来攻击。 相反，仅仅因为系统中还没有发现（或公布）安全漏洞并不意味着不存在或可能存在。 需要在项目的设计阶段规划安全性，并规划如何在应用程序的生存期内维护安全性。

安全性设计

开发安全应用程序时最大的问题之一是，安全性通常是事后需要实现的，项目完成代码后需要实现。 如果在开发初期没有将安全性纳入应用程序，那么由于对应用程序安全性的考虑不足，这将导致应用程序不安全。

临时或仓促的安全措施可能导致更多的漏洞，因为软件在新的限制下出现故障，或必须重写软件以适应未预料的功能。 每行修订的代码都包含引入新 bug 的可能性。 因此，你应该在开发过程中尽早考虑安全性，以便它可以与新功能的开发一起进行。

威胁建模

除非你了解系统暴露的所有潜在攻击，否则无法保护系统免受攻击。 评估安全威胁的过程（称为 威胁建模）是确定 ADO.NET 应用程序中安全漏洞的可能性和影响所必需的。

威胁建模由三个高级步骤组成：了解对手的观点、确定系统的安全性以及确定威胁。

威胁建模是一种迭代方法，用于评估应用程序中的漏洞，以查找最危险的漏洞，因为它们暴露了最敏感的数据。 确定漏洞后，可以按严重性顺序对它们进行排名，并创建一组优先的对策来应对威胁。

有关详细信息，请参阅以下资源：

最低特权原则

设计、生成和部署应用程序时，必须假定应用程序受到攻击。 这些攻击通常来自使用运行代码的用户权限执行的恶意代码。 其他情况可能源自被攻击者利用的意图良好的代码。 规划安全性时，请始终假设会发生最坏的情况。

一个可以采用的对策是在代码周围建立尽可能多的保护措施，并尽量以最低特权运行。 最低特权原则表示，任何给定权限都应授予在最短时间内完成作业所需的最少代码量。

创建安全应用程序的最佳做法是根本不具有任何权限，然后为所执行的特定任务添加最窄的权限。 相比之下，从所有权限开始，然后拒绝单个权限会导致难以测试和维护的不安全应用程序，因为安全漏洞可能来自无意中向所需的更多权限授予。

有关保护应用程序的详细信息，请参阅以下资源：

代码访问安全性 (CAS)

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

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

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

• 使代码能够请求其运行所需的权限、希望拥有的有用权限，以及明确指定代码绝不可拥有的权限。

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

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

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

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

为了最大程度地减少攻击成功时可能造成的损害，应为代码选择一个安全上下文，仅允许访问完成其任务所需的资源，而不多于此。

有关详细信息，请参阅以下资源：

数据库安全性

最低特权原则也适用于数据源。 数据库安全性的一些常规准则包括：

• 创建具有最低特权的帐户。

• 不允许用户仅访问管理帐户即可使代码正常工作。

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

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

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

• 为正在使用的数据库启用安全审核和日志记录，以便收到任何安全漏洞的警报。

有关详细信息，请参阅以下资源：

安全策略和管理

管理代码访问安全（CAS）策略不当可能会造成安全漏洞。 部署应用程序后，应使用监视安全性的技术，并在出现新威胁时评估风险。

有关详细信息，请参阅以下资源：

另请参阅

• 保证 ADO.NET 应用程序的安全
• .NET 中的安全性
• SQL Server 安全性
• ADO.NET 概述