本文简单回顾了 API 的发展历史，其基本概念、功能、相关协议、以及使用场景，重点讨论了与之相关的不同安全要素、威胁、认证方法、以及十二项优秀实践。  

根据有记录的历史，随着 Salesforce 的销售自动化解决方案的推出，首个 Web API 在 1990 年底出现了。在那个时候，它是一种每个人都可以访问到的开放资源。Salesforce 的自动化工具由 XML 驱动。而用于交换该工具信息的数据格式，后来被公认为 SOAP API 标准。它拥有与允许或禁止各种请求相关联的消息格式规范、以及特定于代码的规则。也就是说，大多数开发人员除了需要针对 API 的开发和创建进行必要的 SOAP 处理，也需要手动将 XML 文档与 RPC 协同使用。之后，开发人员还需要解释 API 的端点（调用淘宝，拼多多，京东，1688，亚马逊API接口），并将 SOAP 套件发布到该端点处。这不仅是 API 的诞生，也算是 SaaS 概念的开始。

而塑造现代 API 的关键事件，离不开 Flicker 和 Facebook API 的推出。Flicker 开发了一个通过云端存储数字图像的平台，该平台通过开发 API，支持横跨不同平台的图像共享，并集成了各种照片共享设施的新型服务。

到了 2008 年，API 进化成为可以独立操作，并能够处理大量互连的信息。Twilio 通过推出一个 API，可方便用户连接电话、短信等整个产品所需各个部分。

什么是 API?

对于初学者来说，API 是指为两个不同的应用之间实现流畅通信，而设计的应用程序编程接口。它通常被称为应用程序的“中间人”。由于我们需要保护用户的持有数据、以及应用本身的完整性，因此 API 的安全性是一种“刚需”。

而对于开发人员而言，API 是一个非常好的工具。它可以在微服务和容器之间交换信息，并实现快节奏的通信交流。正如集成和互连对于应用开发的重要性那样，API 在某种程度上，驱动并增强了应用程序的设计。

API 风靡互联网

在互联网的早期，API 作为专有协议，在网络中往往被用于受限的区域、目的或组织，让不同网络架构的通信与计算成为可能。当 Web 2.0 出现后，基于 Web 的工具广泛涌现，人们开始使用 REST （REpresentational State Transfer Framework）这一社区开发规范，来构建实际应用的 API 接口，例如我们常见的 OpenAPI。

在如今的 Web 3.0 时代，API 在 IoT 和 AI 驱动的设备之间的通信中，发挥着至关重要的作用。API 的常规请求 - 响应范式也转变成为了事件驱动的方式。

API 用例

API 作为方便信息交换的基本元素，被广泛用于 Web 应用程序的开发领域。目前，业界最常使用且最为重要的 API 用例，有如下类型：

单页应用程序（SPA）

REST API 不但可以加速单页应用程序的开发，而且能够协助应用将所有内容放在一张页面上，以提供完整的用户体验。在应用的开发过程中，程序员可以使用预定义的 CSS、JavaScript 和 HTML 文件，来启动 Web 服务器间的通信。注意，REST 框架通常被用于服务器端的通信，以及针对特定类型框架的客户端信息交换。

常被用于 SPA 开发的 REST API 框架包括：NancyFx、Express.js 和 ASP.Net WebAPI。作为无状态的框架，REST API 不会受到客户端为每个请求去调用一到多个服务器的困扰。因此使用 REST API 进行 SPA 开发，能够提高应用的可扩展性。显然，这不但减轻了开发者为扩展应用程序而付出的成本，并且消除了应用对于访问特定资源的需求。

在 SPA 开发中，除了 REST API 文档之外，没有其他元素会被绑定到客户端和服务器上。因此，这种独立性促进了应用在开发、测试和部署环节的灵活性。而这恰恰是动态网页框架所无法达到的。

公共 API、企业级的 B2B

长期以来，电话、传真和电子邮件一直是 B2B 运营的主要通信手段。然而，为了满足基于物联网的信息交换的需求，RESTful API 可以在自动化的企业级 B2B 通信方面，发挥关键性的作用。

从客户的角度来看，发布公共 API 会使得企业能够创建面向消费者的应用程序，并且最大化与外界的通信交流效果。同时，由于公共 API 允许 B2B 客户端扩展各种基于用户的行为，因此它使得业务流程得以充分解耦，并在不增加成本负担的前提下，增强了基于机器（machine-based）的互操作性。

私有 API 与内部 API 服务

使用私有 API，B2B 客户可以缩短面市的时间，并在加速启用新的应用和工具的同时，不会对现有工作流程造成瓶颈。在管理内部工作流时，私有 API 可以为企业找出需要重组和现代化改造的可组合（composable）领域。而作为一个创造性的过程，可组合的业务模型可以将复杂的功能分解为，易于处理的微型部分。私有 API 通过支持内部各个级别的高效通信，促进了资源的战略性使用。

由于内部 API 提供了针对各种可能导致操作性故障，以及提高系统部件响应时间的详细信息，因此它使得商业智能分析的结果更加精准。而且在使用私有 API 后，应用的协作和信息交换能力也会变得更加快速且安全。

服务网格

作为基础设施层的组件，服务网格具有高度的可配置性和低延迟性。通常，它被用于在网络结构中，处理大规模的内部通信。通过合理地使用网格，开发者可以保证各种与容器化和临时应用相关的快速、安全且可靠的信息交换。

API 可以被用于服务网格中的信息交换。不过当网格的数据平面与通过系统的每个数据包或请求进行联系时，情况会变得复杂许多。因此，使用通用数据平面（Universal Data Plane）和 xDS 等 API 可以简化此类工作。它们可以检查系统的健康状况，监控其性能、路由各种传入或传出请求、以负载共享的方式平衡系统流量，以及通过服务发现的方式，来发现与用户授权相关的误操作。

移动后端

作为一种新兴的服务交付模型，移动后端通常被用于移动优化方案的开发中。被称为移动后端即服务（Mobile Backend as a Service，MBaaS）的开发模型，充分给予了开发人员维护服务器和服务器相关工具的自由，其中包括：用户管理、推送通知和社交登录插件等组件。

MBaaS 的各个资源会使用灵活的 SDK，去连接 API 的端点。例如，MBaaS 会使用 Flutter、Unity、Iconic 和 React Native 等技术，为 Android 和 iOS 操作系统开发前端应用。同时，MBaaS 平台的各种 API 能够为开发人员在工作流管理、通知更新和任务规划等方面带来自动化。

此外，这些 API 可以生成一个应用层，以实现在各种系统和所使用的服务之间，进行无缝的信息交换。开发人员也可以为新添加的用户集群，设计各种基于需求的服务。

物联网（IoT）

由于物联网设备需要连接到客户端、或其他网络用户的设备上，以完成信息的交换，因此在使用 API 时，往往难免暴露交换信息。为此，开发人员需要创建足够安全的、基于上下文的应用，而不可直接使用 UI 与外部进行交互。

REST API 是目前用于物联网设备真实场景的、最普遍的 API，它通过互联网协议来进行信息交换。此外，REST API 也允许开发人员实施身份验证和授权策略。

不同人眼中的 API

API 的多样性往往会被用于不同的应用场景中，而不同角色的开发者，对于 API 有着不同的认识。

后端开发：

• 框架：一个结构良好的规划或战略，它定义了操作和流程的工作方式。

• 规范：一种基于 Swagger 的文档，可描述 REST 或 OpenAPI 等功能。例如，与 Geo PC 内容相关的某种 GraphQL 模式。

• 数据和业务逻辑：后端开发人员更喜欢在客户端（例如，移动应用或浏览器）之间分离数据和逻辑。这将有利于他们自己的代码或数据，例如，单页面应用和移动应用可以使用相同的数据与 API，去处理各种自定义的集成。

• 统一的移动、Web 和集成后端，可以改进和简化同步的过程。

DevOps：

• 满足生产环境的规范：例如，如果端点经常返回 502 错误的话，您就应该考虑使用 API，来对其进行修复。

• 可扩展性：如果端点需要通过扩展，来解决 504 错误的话，您需要找出与此相关的微服务、最佳流程、以及解决问题的方向（例如，针对 GraphQL 的 REST API）。

API 的工作原理流程图

安全：

• 新的协议：如何应对防火墙、扫描仪和其他旧工具停止升级的问题？

• 东 - 西向（East-west，即各个后端应用与数据库之间，区别于我们常说的南 - 北向）安全：在网络内缺乏对通信的良好监控。

• 新的安全、网络或其他 IT 组件的合规性需求。

API 安全的重要性

如前所述，API 与 API 安全是相辅相成的。那些安全性较差的 API，往往容易暴露，且受黑客的攻击。而由于 API 主要用于交换信息、连接服务和传输数据，因此一旦出现数据泄露，就会给企业带来重大的损失。

API 的各种认证方法

在授予用户访问权限之前，我们有必要验证那些查看或编辑 API 资源的用户的真实身份，以防止 API 被不恰当地使用。

1、基于主机的认证

该过程通过验证主机或服务器，以保证只有经过验证的用户，才能访问到部署在服务器上的资源。我们并不需要任何密钥、或其他方式，来启动该过程。但是，服务器应该有能力通过实时验证登录密钥，以控制 DNS 欺骗、路由欺骗、以及 IP 欺骗等事件。

在流程和实现方式上，基于主机的认证与 RSA 非常相似。默认情况下，我们可以不必设置任何参数。基于主机的用户验证，可以由管理员通过为本地主机创建私钥、或提取用于本地主机的公钥来完成。

2、基本认证

这是最直接的 API 身份确认方案之一。由于客户端发送带有预构建标头的 HTTP 请求，因此，该方法使用 HTTP 协议和进程，来请求和验证用户名和密码等凭据。此类检查往往是在浏览器驱动的环境中完成的。

由于能够得到绝大多数浏览器和服务器的支持，因此此类身份认证所使用到的凭据详细信息，可以明文形式在网络上共享，或仅使用 base64 进行编码。它不但能够在各种代理服务器上运行，而且能够将访问权限授予那些并未托管在 IIS 服务器上的资源。由于缺少加密的保护，因此它很容易受到重放等方式的攻击。

3、OAuth

作为一种可定制的开放式 API 身份验证技术，OAuth 可以通过验证用户身份和定义授权标准，实现应用与服务器、及存储类 API 的交互。

当有人登录系统时，它会通过请求令牌的方式，去验证用户身份。为此，个人或请求的创建者必须将访问资源的请求，转发到身份验证服务器上。服务器进而会根据验证的结果，对请求予以接受或拒绝。

相比其他流程，OAuth 更为安全，因此它成为了许多用户的首选。OAuth 的三个关键要素包括 OAuth 提供者（如 Google 和 Facebook）、OAuth 客户端（指承载信息的网站 / 页面）、以及所有者（指提出访问请求的用户）。

4、OAuth 2.0

作为 OAuth 的更新版本，OAuth 2.0 是一种被广泛使用的 API 访问管理协议。其功能包括通过使用 HTTP 服务，来启动客户端应用，进而限制 API 客户端的访问。GitHub 和 Facebook 都在其关键性 HTTP 服务的身份验证代码中，使用到了该协议，进而免去了用户凭据。

OAuth 2.0 的三个关键要素分别是：拥有数据的用户、应用程序和 API 本身。在身份验证的过程中，该方法可以很容易地解析到使用不同资源的用户数据。它可以根据验证目的，被部署到基于 Web、移动及桌面的应用程序与设备中。

5、SAML

安全断言标记语言（Security Assertion Markup Language，SAML），是使用单点登录技术进行身份验证的标准化 API 流程。它会根据用户提供的详细信息来进行验证。只有完成验证，用户才会被授予针对各种应用程序或资源的访问权限。目前，SAML 2.0 是被普遍使用的版本。它与 ID 非常类似，可以协助完成对于用户身份的评估。

API 安全意味着什么？

API 安全不仅专注于保护那些直接或间接暴露给用户的 API，还涉及到节流、速率限制等网络安全原则，基于身份的安全分析，以及如下关键性的安全控制概念：

访问控制	限速
OAuth 授权与资源服务器	速率限制、配额
各种访问规则的定义和执行	峰值保护
统一管理和执行

内容验证	监控和而分析
输入/输出内容验证	基于人工智能的异常检测
机构与模式规则	各种API调用的顺序检查
基于签名的威胁检测	地理栅栏和速度检查

API 协议

API 可以根据不同的需求，以多种形式和样式被使用。而不同的使用方式也决定了 API 实施的安全性。

SOAP

简单对象访问协议（Simple Object Access Protocol，SOAP）是一种基于 XML 的消息传递与通信协议。该协议可以扩展 HTTP，并为 Web 服务提供数据传输。使用该协议，我们可以轻松地交换包含着所有内容的文件、或远程调用过程。与诸如 CORB、DCOM 和 Java RMI 等其他框架的不同之处在于，SOAP 的整个消息都是被写在 XML 中的，因此它能够独立于各种语言。

REST

作为基于 HTTP 协议的 Web 标准架构，REST 针对每个待处理的 HTTP 请求，可以使用四种动词：GET、POST、PUT 和 DELETE。对于开发人员来说，RESTful 架构是理解 API 功能和行为的最简单工具之一。它不但能够使得 API 架构易于维护和扩展，而且方便了内、外部开发人员去访问 API。

gRPC

作为一个开源的高性能框架，gRPC 改进了老式的远程过程调用（Remote Procedure Call，RPC）协议。它使用 HTTP/2 这种二进制帧传输协议，简化了客户端和后端服务之间的通信和消息传递过程。

完全轻量级的 gRPC，要比 JSON 快 8 倍以上。它可以通过开源技术协议调用缓冲区，并对结构化的消息采用了一种与平台无关的序列化格式。在 API 的使用中，开发人员可以通过 gRPC，找出应该调用和评估参数值的各个过程。

Webhook

Webhook 能够将自动生成的消息，从一个应用程序发送到另一个应用程序。换句话说，它可以在两个应用之间实时建立、发送、提取更新的通信。

由于 Webhooks 可以包含关键信息，并将其传输到第三方服务器，因此我们可以通过在 Webhooks 中执行基本的 HTTP 身份验证、或是 TLS 身份验证，来保证 API 的相关安全实践。

WebSocket

WebSocket 是一种双向通信协议，可以在客户端和服务器之间提供成熟的双向通信通道，进而弥补了 HTTP 协议的局限性。

应用客户端可以使用 WebSocket 来创建 HTTP 连接请求，并发送给服务器。当初始化通信连接被建立之后，客户端和服务器都可以使用当前的 TCP/IP 连接，根据基本的消息框架协议，传输数据与信息。

XML-RPC

XML-RPC 可以通过标准化的通信过程，实现 WordPress 和其他系统之间的相互通信。它使用 HTTP 作为传输的手段，使用 XML 作为编码过程。其工作代码被存储在位于网站根目录的 xmlrpc.php 文件中。作为 WordPress 3.5 版的默认选项，XML-RPC 能够让移动应用与基于 Web 的 WordPress 安装过程，实现无缝的交互。

不过，对于每个访问请求而言，由于 xmlrpc.php 能够共享身份验证的详细信息，因此它增加了暴力攻击和 DDoS 攻击的几率。对此，我们在采用 XML-RPC 的 API 时，需要增加相关安全实践。

JSON-RPC

对于新手而言，JSON-RPC 是一种超轻型的 RPC 协议，可用来开发基于以太坊区块链的 API。它采用 JSON（RFC4627）作为基本的数据格式，具有解释和处理多个数据结构与规则的能力。该协议可以通过相同的套接字被反复使用。

MQTT

MQTT 是 OASIS 认可的消息协议，已被广泛地用在物联网设备和工具开发领域，实现了 HTTP 类型的信息交换。由于非常轻巧，因此它可以让开发人员能够一次性扩展到数百万台设备上。在 API 安全性方面，MQTT 不但能够协助实现消息加密，而且可以轻松地应用 TLS 和身份验证。

AMQP

作为一个开放的协议，高级消息队列协议（Advanced Message Queuing Protocol，AMQP）规定了消息提供者的行为过程，可以被应用到应用层上，创建互操作式的系统。由于是采用二进制实现的，因此该协议不但支持各种面向消息的中间件通信，而且可以确保消息的全面妥投。

XMPP

作为一整套免费的源技术，XMPP 可用于开发多方协作、即时消息、多方聊天、视频通话、以及轻量级中间件等领域。它的四个关键性组件包括：PHP、MySQL、Apache 和 Perl。

CoAP

作为一种由 RFC 7252 定义的 IETF 标准，CoAP 可以被当作标准化的 API 安全协议，来约束物联网设备上的应用。由于 CoAP 可以支持通过 LPWAN 进行通信，因此它是保护简单微控制器节点的最佳选择。CoAP 工作在 TCP/IP 层，并采用 UDP 作为基本的传输协议。

云、本地和混合部署中的 API 安全

云服务、集成平台和 API 网关等技术领域的发展，使得 API 提供商们能够以多种方式来保护 API。可以说，针对构建 API 所选择的技术栈类型，会对保护 API 产生直接的影响。例如，一个大型组织可能会使用多个带有自研 API 的应用程序。而在他们合并各种应用的过程中，可能会造成各种 API 孤岛的出现。这些孤岛往往就是安全隐患的所在。

在异构生态系统中，跨 API 孤岛的特定 API 安全基础架构，可以被配置为 sidecar、sideband 代理，嵌入到云端与本地的部署之间。由于具有高度可移植性，因此此类安全配置可以方便任何面向未来的技术，轻松地传输或提取 API。

API 安全层

API 安全层应该是多层次的结构。各个层面各司其职，最大程度地提供安全保护。

API 发现

API 安全的第一层是 API 发现，毕竟如果不知道目标与威胁，何谈如何实施保护。如前所述，API 孤岛是阻碍安全人员发现 API 的首要问题。由于缺少 API 的可见性，它将直接妨碍 API 访问权限的管理。

影子 API 是 API 可见性的第二大障碍。当 API 作为应用的一部分被开发时，往往只有开发小组成员对其了如指掌，而安全人员对此类“影子 API”的实施细节不得而知。

第三大障碍便是 API 版本控制。在软件应用的生命周期中，其 API 通常需要不断地进行迭代。可是新版本的 API 往往不能立刻且全面地替换掉旧的版本。由于用户端的应用版本不尽相同，因此旧版本的 API 需要根据向后兼容的需求，继续运行一段时间。然后呢？它们会逐渐离开开发团队的视野，甚至被遗忘。这一切都是悄然发生的。

因此，API 发现实际上是 API 提供者和攻击之间的竞赛。如果提供者能够在攻击者之前发现上述类型的 API，那么他们便可以从 API 网关、负载平衡器、以及直接内联的网络流量中提取 API 的流量元数据，并通过专门的引擎，生产有效的 API 列表报告，以便与 API 管理层上的可用 API 目录进行比较。

API 安全的 OWASP 十大安全威胁

API1:2019 对象级别授权的缺陷

通常，API 端点通过发现处理对象的标识符，来获取访问控制层面的攻击。我们需要针对由客户端提供的信息，进行逐条检查。

API2:2019 用户认证的缺陷

攻击者往往会利用获取到的令牌、或验证系统的执行缺陷，来冒充合法用户，并执行非法操作。

API3:2019 过度的数据暴露

攻击者可以通过 API 的调用，合法获取的数据，推断出某些条目的相关属性，进而筛选出各种实用的信息。

API4:2019 资源不足和限流

通常，API 不会对被调用的数据进行流量或数量上的限制。而这就给攻击者留下了发起拒绝服务（DoS）等抢占资源类攻击的机会。

API5:2019 功能级授权的缺陷

有些 API 在复杂的访问控制策略上并不完备，甚至带有授权上的缺陷。这会导致攻击者可以通过函数调用，获得其他用户能够调用的资源。

API6:2019 批量分配

为了提高效率，以 JSON 方式为用户提供信息的模型，往往会提供批量分配（Mass Assignment），而无需根据具体的许可名单，进行合法的属性筛选。据此，攻击者可以通过仔细阅读配套文档，来推测出对象的属性、查找到不同的 API 端点、或在请求负载中发掘额外的属性，进而对它们进行篡改。

API7:2019 安全配置的错误

安全配置的错误往往源于不完备的默认设计、随意的编排、开放的分布式存储、HTTP 标头的错配、宽松的跨域资产共享（Cross-Origin asset sharing，CORS）、以及包含着敏感数据的冗长错误消息提示等方面。

API8:2019 注入

攻击者的有害信息可能会骗过输入检查，在未经适当检验的情况下，利用 SQL 或 NoSQL 的缺陷，执行恶意命令或获取信息。

API9:2019 资产管理不当

API 通常能够发现比常规 Web 应用更多的端点，这使得适当地更新配套文档就显得格外重要了。对此，我们应当持续完善 API 的相关表格，及时发现那些未被记入的端点。

API10:2019 日志和监控不足

缺乏日志记录和检查，加上事件响应能力不足，都会给 API 调用带来被攻击的威胁。

渗透测试

开发人员可以考虑使用 Postman 代理的预构建的 API 测试数据，直接与 API 进行通信。通过快速且反复地开展针对 API 的渗透测试，我们可以在降低测试成本的基础上，获取详细的报告。

由于渗透测试需要对目标 API、乃至整个系统都非常熟练，因此我们最好聘请熟练的安全团队、或使用开源的工具，去模拟针对 API 的攻击。通过定期且持续的渗透测试，开发人员将能够及时找到符合 API 保护级别的补救措施。

12 项 API 安全的优秀实践

由上述讨论可知，API 的安全性对于以数据为中心的应用开发来说，是至关重要的。下面让我们来讨论针对 API 的不同类型与阶段的安全优秀实践。

1、使用加密

为了防范破解类的攻击，我们需要对那些被用在内、外部通信的 API，使用 TLS 加密协议，并部署端到端的加密。

2、API 认证

如前文所述，身份验证可以确保 API 不会被陌生人所直接使用。同时，通过 API 密钥或访问认证，我们可以踪调 API 资源的调用。当然，此类安全措施也会增加系统的实施难度。

3、充分利用 OAuth 和 OpenID Connect

OAuth 和 OpenID Connect 的结合能够为 API 的身份验证和 / 或授权，承担全部的责任。例如，在授权过程中，API 的消费者和提供者均不直接进行授权操作，而是让 OAuth 作为委托协议，为 API 添加一个基本的保护层，并在此基础上让 OpenID Connect 标准作为额外的身份层，使用 ID 令牌去扩展 OAuth2.0。

4、安全专家

面对多种 API 安全实践，您也许会犯“选择困难症”。此时，经验丰富的安全专家可以指导您使用合适的防病毒系统、以及 ICAP（Internet Content Adaptation Protocol）服务器，来构建稳固的 API 安全态势。

5、持续监控、审计和日志记录

常言道，预防胜过弥补。我们可以在 API 设计之初，就设置好待监控与记录的指标；而在应用服务的使用过程中，通过适当的仪表板去跟踪 API 的交互，并及时审查相关记录与错误信息。同时，在后续的调试与版本更新环节，请不要忘记让所有的 API 都得以同步。

6、仅共享有限的信息

记住，您通过 API 共享出去的信息越少，API 自身的安全性风险就越小。同时，您也应当确保在错误消息中，披露的信息尽可能地少。

此外，使用 IP 地址的白名单与黑名单，是限制 API 资源访问的好方法。它可以保证只有已授权人员或应用，才能有限地访问 API 资源，并保持接口上关键信息的隐藏性。

7、限流和配额保护

请根据后端系统、实际带宽、以及服务器的运能，合理地限制有限数量的消息，去访问某些 API，进而能够有效地防范 DDoS 攻击的威胁。

8、有效的数据

服务器应当对接受到的所有内容，进行两次检查与验证。任何新增的内容、庞大的数据集、以及由消费端共享来的信息，都应当经过验证。目前，JSON 和 XML 验证是两种被用于检查参数安全性的最广泛工具。同时，它们也可以控制 SQL 注入、以及 XML 炸弹等事件。

9、强大的基础设施

通过实施最新的安全网络技术、新型服务器与负载平衡软件，我们可以在基础设施的层面上保持 API 的安全性，使之能够抵御大数据量的泄露攻击。

10、关注 OWASP Top10

通过上文分析，您不难看出，OWASP 罗列和诠释出的十大 API 漏洞威胁，是一些最常见的攻击影响方式。它们不但对于 Web 页面，对于 API 的各种漏洞也具有极强的危害性。因此，我们需要事先做好代码级的防范工作。

11、使用 API 防火墙

为 API 构建防火墙可以起到两方面的好处：

• 可用于执行基本的安全检查，例如：检查消息的大小、被 SQL 注入的可能性、以及是否可以立即阻断攻击。

• 可在局域网内部融入现有的防护体系，协同提高整体安全态势。

12、部署 API 网关

无论是供内网使用，还是供外网调用，API 所处的环境往往既复杂又危险。因此，为了减轻管理 API 的压力，我们可以通过部署 API 网关，对 API 的相关流量进行全面的控制、监控和保护。