Windows Server 上 N 层应用程序中的应用程序安全

• 下载图片 - 536.35 KB

目录

1. 为什么需要安全
2. 缩略语和术语
3. 安全层架构
4. 安全实体
5. 安全威胁
6. 安全上下文
7. 上下文分离
8. 超越服务账户框架
9. 结论

1. 为什么需要安全

如今，软件应用程序在各种平台上构建和运行，数量达数百万。这些应用程序对各类用户开放，包括开发人员、内部员工、客户、最终用户、随机用户、专业黑客等。因此，在互联网上开放的应用程序更容易受到未经授权的使用和恶意威胁，这些威胁通过窃取应用程序中的机密数据、创建垃圾数据、修改控制数据、施加重载、破坏系统并使其瘫痪，或远程控制系统，不断挑战应用程序。俗话说，预防胜于治疗，因此，在开始任何系统应用程序设计之前，明智的做法是进行威胁建模，以减轻可能利用应用程序集群中不同服务器普遍存在的配置弱点的此类攻击。通过安全措施，我们建议唯一地识别您的应用程序和服务的客户端。只有正确的用户才能处理经过身份验证的客户端被允许访问的资源和操作。资源包括文件、数据库、表、行等，以及注册表项和配置数据等系统级资源。审计数据对于执行业务规则验证的操作同样重要。例如，如果用户每月只能获取一次银行对账单，则在任何情况下都不应允许他获取两次。这还进一步要求保护他的数据隐私，其他任何人都无法读取。数据完整性是另一种形式的安全威胁，任何用户都不能意外或故意修改数据。有些人认为，即使存在通过拒绝服务攻击来使应用程序崩溃的攻击者，合法用户也永远不应被拒绝获取其信息。

2. 缩略语和术语

术语	含义/表达
资产	有价值的资源，例如数据库或文件系统中的数据。一种系统资源。
攻击/利用	某人或某物对资产造成损害的行为。这可能是某人实施威胁或利用漏洞。
ACL	访问控制列表
对策	解决威胁并减轻风险的保障措施
操作系统	操作系统
威胁	可能发生（恶意或其他）的事件，可能损害或危及您的资产
漏洞	系统某个方面或功能中的弱点，使得威胁成为可能。漏洞可能存在于网络、主机或应用程序级别。
MDI	多文档界面
WinForm	在桌面/笔记本电脑上运行的表单应用程序，无需任何支持的 Windows 服务。它们以可执行文件的形式存在。
ASP.NET	与 Windows Server 中托管的 IIS 结合运行的 .NET 版本应用程序
IIS	Internet 信息服务器用于 Windows 网站托管
AD	Active Directory

3. 安全层架构

根据应用程序架构，安全层可以以多种形式定义和应用。本文基于围绕典型的 N 层 ASP.NET 应用程序应用安全性，该应用程序分布在多种技术、平台和物理网络上。该架构可以强制执行分层安全方法，以减轻来自网络内部和外部的安全威胁。该安全解决方案基于已在 Microsoft 技术上实现的分布式应用程序，由 ASP.NET、ADO.NET、IIS 6.0、WCF、Web Service、COM+、MSMQ、SQL Server 2005 和 Windows Server 2003 支持。尽管未来服务器和服务的版本可能有所不同，但安全方法的实施保持不变。让我们看看应用程序的架构。

4. 安全实体

安全泄露可能发生在多个访问点，从用户交互到可能对应用程序构成威胁的自身用户。恶意意图通常应用于各种计算资源，包括硬件和软件组件。在典型的 ASP.NET 应用程序中，用户交互形式的恶意攻击分为三类，我们希望使其安全和健壮。它们如下：

• Web 浏览器或第三方桌面应用程序

  在现代，有几种网络浏览器已经进入市场。主要的有 Internet Explorer、Mozilla Firefox、Opera、Safari。这些实体属于互联网用户，所以我们没有很多选项来控制它们。

• Web 服务器

  当前解决方案基于 ASP.NET Web 应用程序。该应用程序向使用浏览器读取和写入信息的应用程序用户提供 Web 表单。带有 Service Pack 3 的 Windows Server 2003 企业版将是该服务器的一个示例。服务器内部还有其他需要保护的资源。例如，共享文件夹审计和日志记录、服务、文件和目录、注册表、帐户、MSMQ 和其他 Windows 组件，如 COM+。该组件可以远程管理，因此提供加密的通信通道并使用 IPSec 来限制可用于最大程度减少对它们的任何攻击的计算机。我们可以限制管理员帐户的数量。但是，我将这部分排除在本论文的范围之外。

• 企业客户端应用程序

  它们是应用程序的桌面版本。它们可以是 MDI 或基于对话框的 WinForm/WPF 应用程序。它们是可执行文件，直接从笔记本电脑或台式机运行。无需浏览器。

• 网络和防火墙

  客户端计算机、Web 服务器、代理服务器、应用程序、数据库服务器通过网络连接，并受防火墙保护。计算机属于一个域，该域将拥有一个 Active Directory。给定的用户和计算机可以存在于一个域中。典型示例是“web01.domain.net”，一台机器“web01”可以称为“web01.intranet.domain.net”，用户“user1”可以称为“user1@intranet.domain.net”。协议和端口是路由器、交换机、防火墙需要保护的主要示例。

• 数据库

  通常，数据库用于存储与日常客户交易相关的数据或控制应用程序的主数据。市场上有许多优秀的数据库，如 SQL Server 2005、Oracle 10g 和 MySQL 5.0 等。在本解决方案中，我们将参考 SQL Server 2005 企业版。数据库包含属于客户端最有价值的数据。数据通过网络分布在多个文件中。数据必须在物理和逻辑上保持安全，以便任何未经授权的人都无法访问它。

• 应用服务器

  它们再次是 32 位 Windows Server 2003，尽管可以升级以解决其他性能问题。为了简单起见，我们将继续使用 Windows Server 2003 解决方案。它们通常安装有 IIS、MSMQ 和安全警报等。

• 应用程序本身

  应用程序是攻击的第一接触点和主要关注点。因此，任何形式的用户请求到应用程序都必须通过安全检查。黑客或恶意用户可以针对多个区域进行攻击。

5. 安全威胁

具有恶意意图的用户可以访问不属于他们的资源或数据。根据上图中的架构，该应用程序看起来不够安全，容易被攻破。（图中未显示一些现有的链接。例如，存在从互联网用户到应用程序服务器或数据库服务器的链接。）获得 Web 服务器访问权限的人可以轻松攻入应用程序的数据层，并从那里访问 SQL Server。

在软件应用程序部署的 IT 基础设施中，采用了许多工具和成熟技术。人们认为这些工具在减少任何安全威胁方面效果非常好。这在所有方面都是正确的，但由于不遵守使用策略，安全性被破坏，漏洞和缺陷暴露无遗。

最著名的了解安全漏洞发生地点的模型是 STRIDE。应用程序的安全威胁可以根据攻击的目标和目的进行分类。本文简要介绍这些可以通过 ASP.NET 应用程序在框架本身的支持下缓解的攻击。但是，详细讨论超出了本文的范围。

• 欺骗。欺骗是提供虚假身份以代表他人获取访问权限。攻击者成功地以合法用户或主机的身份获取访问权限后，就可以开始提升权限或滥用授权。服务帐户的实现可以处理大部分此类攻击，无论是来自互联网还是内部网/本地机器代码。
• 篡改。篡改是未经授权的数据修改。这些攻击部分由 ASP.NET 本身的原生实现处理。ASP.NET 采用了各种机制，如 UI 验证、XSS 验证、视图状态加密、配置数据的单向哈希，以遏制这些攻击。
• 抵赖。抵赖是用户（合法或否则）否认他们执行了特定操作或事务的能力。身份验证和授权矩阵将是应对此类攻击的非常好实现。
• 信息泄露。信息泄露是不必要地暴露私密数据。包含数据库连接字符串和连接详细信息的网页，以及可能导致内部系统级详细信息暴露给客户端的弱异常处理。任何这些信息对攻击者都非常有用。这通过 `global.asax` 错误处理模块实现，并将实际异常解释为用户特定的错误消息。不要透露内部系统或应用程序详细信息，例如堆栈跟踪、--- SQL 语句片段等。确保不允许此类信息传播到最终用户或超出您当前的信任边界。在发生异常时安全失败，并确保您的应用程序拒绝访问且未处于不安全状态。不要记录敏感或私密数据，例如密码，因为它们可能被泄露。当您记录或报告异常时，如果用户输入包含在异常消息中，请对其进行验证或清理。例如，如果您返回 HTML 错误消息，则应编码输出以避免脚本注入。
• 拒绝服务。拒绝服务是使系统或应用程序不可用的过程。我们可以确保服务器上的 TCP/IP 堆栈配置经过强化，以防止 SYN 洪水等攻击。因此，配置 ASP.NET 以限制接受的 `POST` 请求的大小，并限制请求执行时间。
• 权限提升。权限提升发生在具有有限权限的用户冒充特权用户以获得对应用程序的特权访问时。因此，服务帐户的实现是该架构提供系统安全性的支柱。

6. 安全上下文

架构的任务是提供组件到组件的服务策略，以高可伸缩性、完整性、稳定性和可用性解决业务工作流，同时不损害安全性。这意味着大致在执行组件中，每一行代码都在拥有该活动的用户帐户下执行。因此，如果应用程序中的表面积减小，我们总能确保没有更多应用程序在服务器上以未知帐户运行。因此，未知代码的范围保持在最小可能性。需要在每个组件中携带用户上下文，并且代码侧的访问检查将确保没有未经授权的代码在合法帐户上执行。

6.1. 安全上下文流

安全上下文从系统用户的存在流向其数据存储。用户身份映射到安全上下文，该上下文在应用程序中执行时随调用一起传递。这意味着数据或计算机资源应由具有访问数据或资源的逻辑权限的有效用户操作。**否则，用户可能会损害不属于他/她的数据或资源。**当用户存在并开始与系统交互时，安全上下文就会创建。安全上下文从用户界面启动，然后由程序进行身份验证，并由另一个程序授权访问一组资源。此类用户操作的身份验证和授权由应用程序安全框架处理，该框架可以集中放置在系统内部、外部提供程序或混合模式下。ASP.NET 框架提供了执行身份验证和授权部分的机制。它们可以通过可插拔的成员资格提供程序进行扩展。上下文流的逻辑堆栈如下图所示：

上下文将随用户数据在应用程序内的异构组件之间流动。应用程序中的代码将始终在某个用户上下文中执行。如果是在桌面环境中，用户上下文是登录到系统或有权登录到系统的本地用户。如果它是 Windows 服务或批处理作业，则在创建服务时始终会配置服务或作业。但是，代码始终可以模拟其他用户，这可能会对安全性构成巨大风险。因此，通过配置服务帐户（第 6.4 节中描述），此类代码的配置高度安全。两个组件之间的安全上下文通信可以通过两种方式发生。

6.2. 同步调用

在分布式应用程序中，大多数参与组件通过同步调用进行通信。因此，安全上下文以域信任、证书、标头或方法参数的形式从一个组件流向另一个组件。因此，客户端带着安全上下文到达服务器组件，如果安全上下文不符合要求，服务器会立即响应客户端。因此，服务器可以模拟调用或将客户端用户上下文映射到服务器用户上下文。由于互联网用户数量庞大，当前解决方案将采用第二种方式，并且在构建内部网应用程序时将使用模拟。用户映射将按服务进行，其中域帐户将用于运行这些服务，以便管理员可以远程控制用户，并且没有本地用户可以渗透到服务器并执行任何代码。

为了确保任何外部用户进入 Web 服务器；删除对本地用户、机器内置用户的所有访问权限。因此，从互联网到服务器的请求通过安全上下文，通过用户界面（例如，浏览器）调用应用程序的某些请求。根据上面给出的安全上下文示例，当用户存在时，他可以浏览托管在 Web 服务器中的 ASP.NET 应用程序。用户在终端（如桌面/笔记本电脑/手机等）登录。客户端机器上的操作系统然后为他创建一个安全上下文，该上下文通过网络传输到 Web 服务器，ASP.NET 应用程序就驻扎在那里。Web 服务器在另一个安全上下文中运行，代表另一个受信任的用户，通常是 Web 服务器中创建的本地用户。通常，这在基于表单的 ASP.NET 应用程序中以匿名帐户运行。因此，来自浏览器的每个调用都将以用户 `IUSER_MachineName` 用户的身份运行 ASP.NET 代码，该用户是服务器内置的。为了消除任何未知用户在 Web 服务器中调用任何代码；在定义的服务帐户中创建新的安全上下文，该帐户通常是具有最少权限的域用户。有关 Web 帐户的默认权限，请参阅 http://support.microsoft.com/kb/812614。该帐户在 IIS 级别配置。

因此，目的是在用户对其拥有权限的数据、资源的上下文中运行用户代码。未经授权的系统访问将违反规则并构成异常。每个操作都必须在已定义用户集的上下文中执行。

系统资源在 IIS 级别使用服务帐户配置，以实现低级别访问。

为了更精细地调整每个低级别资源，可以授予或撤销网站权限。

即使 IIS 允许安全上下文流向系统/代码，服务帐户仍需要更多权限来执行代码。因此，恶意用户安全上下文将在此级别被消除。下一个挑战仍然存在于代理用户，他们是之前经过身份验证的有效用户，或者这是 UI 级别的攻击。对于 UI 级别应用程序攻击，用户输入的验证是最佳解决方案。这些安全部分由 ASP.NET 表单身份验证、身份验证和授权模块管理。关于输入验证、身份验证、授权、配置管理、敏感数据、渗透测试、XSS 攻击、SQL 注入的讨论不属于本文的范围。尽管 IIS7/Windows Server 2008 有多项改进以最小化系统安全性的表面积风险，但我们仍然希望保护我们的应用程序免受恶意用户输入的影响。

Windows 服务的配置方式有所不同。安装实用程序或 MSI 创建器定义要使用的服务帐户。这也可以在 MSI 安装的详细模式下选择。如果在安装期间这些帐户配置不可用，则在服务控制台中进行配置。

要在任何 Windows 服务（例如：Google Update Windows 服务）中配置用户帐户，请在服务控制台中找到该服务，右键单击以弹出配置控制台。

然后进入“登录”选项卡，用户帐户中有两个选项。已配置了一个本地系统帐户，这不是我们想要的。该帐户是一个特权帐户和本地用户。相同的用户也无法由 Active Directory 控制。因此，我们在 Active Directory 中配置一个新创建的帐户 mydomain\myaccount，并具有“作为服务运行”权限。服务帐户在第 6.4 节中描述。

6.3. 异步调用

这些调用在工作流中执行。排队过程不立即依赖于用户交互。用户上下文被抽象并封装在一个自提取令牌中，该令牌由服务组件使用。系统作业或服务代表用户调用。在任何情况下，代码都不会在泛化用户的上下文中运行，其中操作由授权角色或用户执行。

在异步操作中，MSMQ 是首选，因为这些对象在事务操作上提供了良好的持久性、可伸缩性、弹性和稳定性。由于它们可以存在于分布式组件中并承受故障并恢复，我们选择此类解决方案。风险是，未知用户可以从 MSMQ 读取/写入消息。为了最大程度地减少攻击，服务帐户放置在队列管理控制台中。公共队列由域控制，因此它们通过 Active Directory 进行配置。因此，系统管理员可以轻松检测和更改 MSMQ 的行为。但是，私有 MSMQ 服务帐户有点棘手，需要在本地机器上进行手动配置。

因此，读取 MSMQ 的应用程序仅配置了服务帐户才能读取消息，而其他所有人都将被拒绝访问。因此，任何未知/未经授权的人都无法在 MSMQ 中读取/写入任何消息。

6.4. 服务账户和系统用户

上下文以用户身份的形式从一个组件流向另一个组件。因此，为了最大程度地减少未知或匿名用户执行此操作，我们的首要策略是命名发出请求的用户，无论是同步还是异步，无论是来自系统外部还是系统内部。因此，定义在所有物理服务器和网络中可见的用户身份。

Active Directory 是存储用户信息的最佳位置。服务帐户创建为域用户，系统管理员可以输入、修改和删除它们。这是该设计所有安全性的最关键神经中枢。因此，物理安全对此类环境至关重要，并且必须定期审计。系统管理员将密切关注服务帐户，如果出现任何违约服务帐户，该帐户将被删除。如果服务试图代表此帐户执行任何代码，它将暂停执行。信息会立即提供给网络中的所有服务器，例如 Web 服务器/应用程序服务器/数据库服务器。

6.4.1. NT 用户

NT 用户不过是具有对本地计算机有限访问权限的 Active Directory 用户。它们用于代表实际执行者/用户运行代码。服务帐户定义为具有有限服务权限，以执行数据库操作。这些服务帐户类别的任何用户都不应具有管理权限或登录权限。通过此策略，用户代码不会执行太多操作，以降低风险。

6.4.2. 数据库用户

如果登录在数据库服务器中创建，NT 用户也是有效的数据库用户。一些服务帐户可以访问数据库进行读/写操作。这些登录在 SQL 数据库中创建和维护。这可以极大地帮助限制 SQL 注入。但是，在某些情况下，我们不需要用户成为受信任的用户。因此，作为例外，可以在 SQL Server 中创建一个 SQL 用户，以便在没有安全威胁的情况下严格限制使用。

7. 上下文分离

为了在跨多个域、多个 Web 服务器、应用服务器和数据库服务器的分布式应用程序上实现高安全性，系统需要对易受攻击的资源进行仔细规划和威胁评估。列出了关键资源，并确定了可以访问这些资源的特定用户。即使黑客通过一些不正当手段在服务器上放置了一段代码，由于未知的安全限制，该代码仍然无法做太多事情。架构中应用了多个访问矩阵，以确保没有未经授权的用户在系统上执行其代码。矩阵包含操作名称、用户名和访问权限。矩阵应与功能域保持一致，以便实际系统用户之间的转换变得流畅。以下是一些解决方案中使用的矩阵。它们是自描述的。

1. 应用程序与操作资源矩阵
2. 应用程序与系统资源矩阵
3. 服务帐户与系统服务
4. 服务帐户与低级别系统资源访问
5. 服务帐户与数据库访问

应用程序与操作资源矩阵示例

SL	操作名称	内容用户
		写入器	审阅者	出版社	Reader	故障排除员
1	添加内容	是	否	否	否	否
2	审阅内容	是	是	否	否	否
3	发布内容	否	否	是	否	是
4	查看内容	是	是	是	是	是

应用程序与系统资源矩阵示例

SL	操作名称	用户
		svc_web1	Svc_db1	Svc_quque1	DBA	管理员
1	运行服务	是	否	是	否	是
2	登录终端	否	是	否	否	是
3	读/写磁盘	否	否	是	否	是
4	发送邮件	否	是	是	否	是
5	写入 MSMQ	是	否	是	否	是
6	访问数据库	否	是	否	是	否

服务帐户与系统服务示例

SL	服务名称	用户
		svc_web1	Svc_db1	Svc_quque1	DBA	管理员
1	网站 (http://www.serverdomain/)	是	否	否	否	否
2	ContentServerHandler 服务 (WCF) 否	是	是	否	否
3	ContentComponent (COM+)	否	否	是	否	否
4	邮件组件	否	是	是	否	否
6	数据库服务	否	否	否	否	是

服务账户与低级别系统资源访问示例

SL	低级别系统资源名称	系统用户
		svc_web1	Svc_db1	Svc_quque1	DBA	管理员
1	磁盘 I/O	读取	读/写特定文件夹	读/写特定文件夹	否	是
2	系统注册表	否	是	是	否	是
3	事件查看器	否	是	是	否	是
4	远程登录	否	否	否	否	是
5	作为服务登录	否	是	是	否	是
6	作为批处理登录	是	是	是	否	否

服务帐户与数据库访问示例

SL	数据库名称	数据库用户
		svc_web1	Svc_db1	Svc_quque1	DBA	管理员
1	登录数据库服务器	否	是	否	是	否
2	执行存储过程	否	提供存储过程名称	否	是	否
3	db_owner	否	否	否	是	否
4	数据库读取器	否	提供表名	否	是	否
5	数据库写入器	否	否	否	是	否
6	Sys_admin	否	否	否	否	否

该矩阵将是基础矩阵，可以在给定项目中进行扩展。安全性的精细调整不应阻碍架构的其他“能力”。然而，为了优化和维护，这些都通过角色管理进行了扩展。它们将在下一节中描述。

7.1. 角色管理

当用户群增长时，他们的访问权限有时会变得难以管理，尤其是在域级别访问方面。因此，将角色映射到用户可以达到目的。用户/角色映射矩阵并不是一个新概念，所以我不会在这里讨论。但是，它们可以从数据库、应用程序和操作系统的角度继承。角色管理有利于控制访问。

7.1.1. Windows 身份验证或 NT 角色

操作系统级别有一些内置组；它们可以用于这种情况。我们可以添加更多组，如 `DiskReaders`、`DBReaders`，并将用户添加到这些组中。运行 Web 处理程序的服务根本不会访问数据库。用户属于生产环境部署目标域的 AD。

7.1.2. 应用程序域内定义的应用程序角色

与应用程序相关的角色可以围绕域操作进行分组，例如 `ContentWriter`、`ContentPublisher`、`WebSiteUser`、`FeedbackProviders` 等。配置服务器应用程序以使用最小权限帐户运行。对于服务，角色要么通过 AzMan 提供程序实现，要么通过启用 COM+ 基于角色的安全性在企业级别实现，并强制执行组件级访问检查。为了保护传输到远程服务组件的流量，请使用 IPSec 加密通道或使用远程过程调用 (RPC) 加密。限制分布式 COM (DCOM) 动态分配的端口范围，或使用静态端点映射将端口范围限制为特定端口。

7.1.3. 数据库角色

数据库级别有一些内置角色，例如 `db_owner`、`db_datareader`、`db_datawriter` 等。这些角色可用于此场景，或通过应用程序角色进行扩展，其中用户可以进行一些读取但不能执行某些写入。这些也可以从应用程序角色继承，然后进行扩展。例如，`ContentWriter` 不能执行发布排序过程，`FeedbackProviders` 可以读取执行 `Read` 存储过程。所有 `StoredProcedure` 的分组以及角色之间的映射在系统设计时预先准备。

7.2. 访问控制列表优化

编辑操作系统资源的访问控制列表，使用角色和服务帐户来允许特定数量的权限。这可以减少并影响大量针对系统的安全攻击，并消除攻击。例如：SQL 注入。即使有严格的 UI 验证，它们也是不可避免的。因此，服务帐户访问控制列表可以限制对组件级任务和数据库级操作的访问。

7.2.1. 文件系统资源和共享文件夹

无论用于运行代码的帐户如何，都要编写最低权限代码。使用代码访问安全来限制您的代码被允许访问的资源和操作，可以通过配置策略或您编写代码的方式来实现。您可以使用代码访问安全来限制程序集访问文件系统区域和执行文件 I/O 的能力。

7.2.2. 网络资源和端口

用户配置文件可以轻松限制网络资源和代理防火墙。域边界将确保安全性，以便适当的用户可以访问系统。跨域访问受到限制，只有已知用户才能被允许读/写远程系统。使用 Internet 协议安全 (IPSec) 或 SSL 来保护 Web 服务器和应用程序服务器之间以及应用程序服务器和数据库服务器之间的通信通道。限制客户端连接到应用程序服务器的端口范围，并考虑使用 IPSec 限制来限制客户端范围。

7.2.3. 系统注册表

系统注册表只能由本地用户写入，因此在域用户下运行的应用程序将无法读取、写入系统注册表值。因此，仔细规划帐户和要访问的注册表节点矩阵将为系统提供精细的访问权限。

7.2.4. 活动目录

Active Directory 由系统管理员管理，不面向互联网。但是，已实施物理安全，并且公司政策足够强大以审计其运作。所有这些服务帐户、服务器、网络、MSMQ 都必须属于此目录。此目录之外的资源将不允许在物理服务器上执行任何操作。

7.2.5. MSMQ 和其他操作系统资源

MSMQ 和系统中使用的其他资源应在 Active Directory 中注册。但是，如果存在私有 MSMQ，则必须将其访问控制列表中添加域用户，并删除匿名和所有人访问权限。

7.2.6. 日志和审计

日志和审计始终高度加密和安全。应进行频繁审计，以确保安全策略永不妥协。

8. 超越服务账户框架

除非我们有第三方保证和测试，否则本文不会得出任何有意义的结论。对于编写代码，它只是一个代码审查工具，可以验证是否报告了任何安全异常。任何代码审查都无法完全消除代码、部署、托管和维护的漏洞。无论用于运行代码的帐户如何，您都可以限制代码的功能。您可以使用代码访问安全来限制代码允许访问的资源和操作，无论是通过配置策略还是您编写代码的方式。如果您的代码不需要访问资源或执行敏感操作（例如调用非托管代码），您可以使用声明性安全属性来确保管理员无法授予您的代码此权限。

建立信任和高水平的职业道德可以最大程度地降低安全威胁。物理安全、数据库匿名化是数据安全的主要关注点，如果不妥善处理，可能会带来危险。更重要的是会话管理、加密、参数操纵、异常管理，以确保不向匿名用户呈现任何域或应用程序相关信息。测试工具总是首选进行测试。HP-Web Inspect 在识别系统中的安全漏洞方面做得非常出色。到目前为止，还没有足够的安全限制被证明是充分的，我们仍然希望堵塞应用程序中的所有漏洞。我已涵盖了威胁可能出现的大部分领域。但是，如果任何不公平的元素在架构的任何地方找到执行其程序的代码，我将希望将其封锁。因此，欢迎任何评估。

9. 结论

这是一个应用于企业级系统的健壮安全框架。必须注意优化，以确保应用程序性能不会下降。如果为了性能而承担任何风险，则必须定期审计和记录，并在维护会议中讨论。