一、应用程序管理的概念
应用程序管理（Application Management，AM）提供应用程序的各种服务、流程和方法，用于维护、增强和管理定制的应用程序，打包的软件应用程序和网络交付的应用程序。AM是一种企业范围的IT治理方法，旨在为组织提供最佳的应用程序性能基准程序，并同时整合业务和IT部门，而且每个部门都具有不通的AM目标。
AM主要利益相关者：
应用程序所有者：这个团队由关键的业务执行人员组成，他们从业务生产力、收入和控制的角度考察AM。
应用程序开发人员/经理：这个团队负责开发、部署和维护应用程序的关键IT企业人员组成。
应用程序人员：这个团队根据应用程序进程和模块的安全性、隐私、版本控制和总体控制来衡量AM。
AM流程包括应用程序生命周期（ALM）、应用程序项目组合管理（APFM）和应用程序性能管理（APM）。
1.1 应用程序生命周期管理
应用程序生命周期管理时信息技术和软件开发组织在应用程序的整个生命周期内创建、部署和运行软件的过程。它是系统开发生命周期管理的另一种形式。
1.2 应用程序项目组合管理
应用程序项目组合管理（Application Portfolio Management，APFM）旨在日常工作之外评估组织的IT基础设施，决定应该何时何地地对程序进行改进。APFM关注的重点是对整个应用程序组合进行全面检查，以更好地决定何时消除、升级、替换或整合应用程序。
应用程序项目组合管理：一种将成本/收益分析和其他业务分析应用于IT决策的技术。APFM将每个程序和设备视为公司总体项目组合中的资产，并根据投入使用的时间、重要性和用户数量等因素对其进行评分。在APFM下，对项目组合升级或变更的进一步投资必须以预期收益和其他可衡量因素为依据。
如下展示了使用策略矩阵描述说明了应用程序项目组合的概念，并展示了IT对企业的重要性。
再造：利用信息技术提高性能并降低成本。再造工程的主要前提是检查组织的目标，并重新设计工作和业务流程，而不是简单地对现有地任务和功能进行自动化实现。
管理应用程序项目组合地策略矩阵是二维地，在下表中定义了其主要的特性：
将每个现有或预期的应用程序分类为四个象限中的一个，有助于项目组合管理。该矩阵支持优先次序和活动建立的时间框架。
1.3 应用程序性能管理
应用程序性能管理（APM）关注的是应用程序如何满足其预期目标并按预期执行。如下定了构成有效APM策略的五个步骤：
应用程序性能管理：在系统管理中以管理和跟踪软件应用程序的可用性和效率为目标的实践。APM涉及将IT指标转换为业务中的术语，同时检查工作流和相关的IT工具，这些工具用于分析、识别和报告应用程序的性能问题，以确保满足企业和终端用户的期望。应用程序性能表现为完成事物或将信息发送给特定应用程序的终端用户的速度。
终端用户监控体验：捕获端到端的性能如何影响用户的数据并识别出所有的问题。这一步是最终重要的。
运行时应用程序架构的发现、建模和显示：研究应用程序执行中涉及的软件和硬件组件，以及他们的通信路径，并由此来确定问题的潜在范围。这一步旨在发现有助于提高应用程序性能的特定组件。
用户定义的事物概要分析：检查用户定义的事物在第2步中定义的路径间的移动情况，以确定问题的根源。这里关注的不是事务的总时间，而是应用程序的哪些部分会花费时间处理事务。目标是确定应用程序的哪些部分或层级消耗的时间最多。
应用程序中组件的深度监控：是深入监控第2步中发现的组件所消耗的资源和其他发生的事件。
分析：最后一步涉及用分析工具处理前4步中生成的数据，发现有意义且可操作的模式，查明问题的根源，并最终预测可能影响终端用户的未来的问题。
二、公司业务应用程序安全
应用程序安全：使用软件、硬件和程序化的方法保护应用程序免受外部威胁。应用程序安全包括向应用程序软件添加特性或功能，以防止一系列不通的威胁。
2.1 业务应用程序登记
应用程序项目组合管理中应该包括所有应用程序的清单或登记簿，包括相关应用程序的详细信息，以及与安全相关的方面。
商业现货（COTS）软件：为满足采购机构的需要，在软件产品的整个生命周期中不需要特别修改或维护的商业上可获得的、出租的、许可的或出售给公共的软件
2.2 业务应用程序保护
与其他业务资产一样，应该将健全的安全体系结构原则应用到业务应用程序上。对于内部开发的和外部开发的这两类应用程序，应考虑的事项有所不同。
1、内部应用程序安全
对于组织内部开发的任何应用程序，必须将安全性纳入SDLC的所有阶段。我们不管是内部开发的还是外部开发的应用程序，都应该采取如下措施：
记录安全需求；
制定评估应用程序安全产品和服务的标准化程序；
强制遵守政府和行业的标准和法规；
制定策略，为每个应用程序定义一个可接受的安全级别；
制定预先部署（pre-deployment）应用程序测试和验证的策略；
制定后期部署（post-deployment）应用程序监控的策略；
制定应用程序代码审查文档的策略；
强制执行常规的修补/维护周期；
上面列出的措施被认为是保证内部应用程序安全的重要内容。这里我们关注的是应用程序自身提供的应用程序安全控制的开发和验证。
2、外部应用程序安全
在应用程序安全方面，内部安全很重要，外部环境也很重要。外部环境包括主机操作系统或虚拟机操作系统、硬件平台和网络连接。外部应用程序安全包括以下内容：
使用操作系统级的访问控制防止未经授权的访问。
通过使用最小特权、职责分离、防火墙和防止应用程序内部工作信息泄露的措施来实现数据机密性。
强制实施虚拟平台安全。
确保应用程序对数据库系统和文件系统的访问具有足够的安全控制。
使用传输层安全协议（TLS）或IP安全协议（Ipsec）对网络流量进行加密。
2.3 基于浏览器的应用程序保护
1、Web应用程序安全风险
开放式Web应用程序安全项目（OWASP）维护的十大风险列表是针对最严重风险的非常有用的指导性文献。
A01:2021-权限控制失效 从第五名移上來; 94% 被测试的应用程式都有验证到某种类别权限控制失效的问题。在权限控制失效这个类别中被对应到的 34 个 CWEs 在验测资料中出现的次数都高于其他的弱点类别。
A02:2021-加密机制失效 提升一名到第二名，在之前为 敏感资料外曝，在此定义下比较类似于一个广泛的问题而非根本原因。在此重新定义并将问题核心定义在加密机制的失败，并因此造成敏感性资料外泄或是系統被破坏。
A03:2021-注入式攻击 下滑到第三名。94% 被测试的应用程式都有验测到某种类別注入式攻击的问题。在注入式攻击这个类別中被对应到的 33 个 CWEs 在验测资料中出现的次数为弱点问题的第二高。跨站脚本攻击现在在新版本属于这个类別。
A04:2021-不安全设计 这是 2021 年版本的新类別，并特別聚焦在设计相关的缺陷。如果我们真的希望让整个产业"向左移动"＊注一＊，那我们必须进一步的往威胁建模，安全设计模块的观念，和安全參考架构前进。
A05:2021-安全设定缺陷 从上一版本的第六名移动上來。90% 被测试的应用程式都有验测到某种类別的安全设定缺陷。在更多的软件往更高度和有弹性的设定移动，我们并不意外这个类別的问题往上移动。在前版本中的 XML 外部实体注入攻击 （XML External Entities）现在属于这个类別。
A06:2021-危险或过旧的组件 在之前标题为 使用有已知弱点的组件。在本次版本中于业界问卷中排名第二，但也有足够的统计资料让它可以进入 Top 10。这个类別从 2017 版本的第九名爬升到第六，也是我们持续挣扎做测试和评估风险的类別。这也是唯一一个沒有任何 CVE 能被对应到 CWE 內的类別，所以预设的威胁及影响权重在这类別的分数上被预设为 5.0。
A07:2021-认证及验证机制失效 在之前标题为 错误的认证机制。在本次版本中由第二名下滑至此，并同时包含了将认证相关缺失的 CWE 包含在內。这个类別仍是 Top 10 不可缺少的一环，但同时也有发现现在标准化的架构有协助降低次风险发生机率。
A08:2021-软件及资料完整性失效 这是 2021 年版本全新的类別，并在软件更新，敏感及重要资料，和 CI/CD 管道中并沒有做完整性的确认为前提做假设并进行评估。在评估中影响权重最高分的 CVE/CVSS 资料都与这类別中的 10 个 CWE 对应到。2017 年版本中不安全的反序列化现在被合并至此类別。
A09:2021-安全记录及监控失效 在之前为_不完整的记录及监控_并纳入在业界问卷中在本次列名为第三名并从之前的第十名上移。这个类別将扩充去纳入更多相关的缺失，但这也是相当难去验证，并沒有相当多的 CVE/CVSS 资料可以佐证。但是在这个类別中的缺失会直接影响到整体安全的可视性，事件告警及取证。
A10:2021-服务器端请求伪造 这个类別是在业界问卷排名第一名，并在此版本內纳入。由资料显示此问题有较低被验测次数和范围，但有高于平均的威胁及影响权重比率。这个类別的出现也是因为业界专家重复申明这类別的问题相当重要，即使在本次资料中并沒有足够的资料去显示这个问题。
2、Web应用程序防火墙
Web应用程序防火墙（WAF）是应对Web应用程序威胁的最重要的工具，这是一种用于监控、过滤或阻塞数据包往返于Web应用程序的防火墙。WAF合理地部署在应用程序和用户之间，以便所有进出应用程序的流量都能够通过WAF。
防火墙有许多模式，包括：
基于网络：基于网络的防火墙是一种硬件防火墙，它与企业网络边缘的路由器相结合，充当所有进出网络设备流量的过滤器。
本地硬件：本地硬件防火墙位于应用程序服务器及其网络连接之间。
本地软件：本地软件防火墙构建在服务器主机操作系统或虚拟操作系统之上。
WAF的开源示例是ModSecurity。它具有跨平台功能，允许Web应用程序放或者获得对HTTP（S）流量的可见性，并提供语言和API实现监控、日志记录和访问控制。
3、其他基于浏览器的应用程序保护措施
除使用WAF外，还应考虑看一些其他的特定安全措施，包括：
通过将文件与服务器上的其他程序隔离并限制文件访问，为配置文件和特定于应用程序的其他信息提供机密性和完整性保护。
网站内容应同样具有机密性和完整性保护。
需要以定期进行内容审核的形式进行监控，确保内容合适且准确。
4、Web应用程序安全策略
Web应用安全策略是一个很好的基础，我们可以参考SANS研究所提供的策略模板进行开展。
三、终端用户开发应用程序
终端用户开发应用程序（EUDA）位于IT组织支持的正式系统之外。通常由业务功能中精通技术的用户开发。
3.1 优点
方便易用：非IT人员可以轻松快速地快速EUDA。
强大地工具和感知技术的终端用户：终端用户工具提供丰富的功能。
信息需求：通常情况下，管理人员往往受到因IT系统中标准报告无法满足所有管理信息和报告的要求的限制。
3.2 风险
用户开发和用户控制的应用程序，通常不像传统应用程序那样受到开发、监控、报告和控制的约束。因此EUDA也存在相关缺点和风险，包括：
错误：可能发生在数据录入时，出现在公式中、应用程序逻辑或与其他应用程序或数据源的连接中。最终错误可能导致决策失误或财务报告不准确。
不良版本和变更控制：与传统IT开发的应用程序相比，EUDA可能会更难控制。即使有变更控制政策存在，也可能难以执行。
不良文档：EUDA的所有权发生变更后，没有正确记录的文件可能会被错误使用，或者它们可能仅仅是使用不当。
缺乏安全性：不安全的文件可能更容易在用户之间交换，这回导致本该保持不变的数据发生变化的风险。
缺乏审计踪迹：审计和控制关键数据变更的能力对于内部治理和遵守外部监控至关重要。
违法法律/法规：对企业负责的安全和隐私，许多法规都有涉及。
未知风险：使用EUDA最大的操作风险是不指导潜在问题的大小。为了量化未知风险，有必要对EUDA的使用情况进行全面的盘点，完成所有关键业务电子数据表的详细风险评估。
机会成本：开发这些应用程序可能会浪费稀缺的资源（金钱或员工时间）。
3.3 EUDA安全框架
为了解决EUDA带来的诸多风险，企业需要一个全面的安全框架来规范管理EUDA的规程并阐明组织的策略。
