确保您的 API 安全：Kong Gateway 顶级安全性的最佳实践

应用程序接口（API）无处不在，它们在我们以数字为中心的生活中几乎无处不在。每次我们在网页或手机上打开应用程序时，后台都在进行数十次 API 调用，以呈现高度个性化的体验。现在，甚至连你家里日常使用的物品都在与 API 进行交互——从亚马逊 Echo 这样的智能音箱，到家用电器、电表和灯泡。

然而，随着 API 的使用不断增长，对 API 安全的需求也随之增加。

企业越来越依赖 API 实现与合作伙伴、供应商和第三方应用程序的无缝集成，而 API 安全漏洞可能会给企业带来严重的财务和声誉损失——有些 API 安全研究报告显示，每次攻击的平均成本约为 610 万美元。

现在，API 已成为恶意行为者（即网络犯罪分子，而非威尔·达福）窃取数据、扰乱运营、实施欺诈和参与一系列其他对企业不利的邪恶活动的主要载体。

随着 API 成为现代应用程序开发的基础，攻击面（即攻击者可能获得未经授权访问网络或系统的所有入口点，以提取或输入数据或执行其他恶意活动）不断扩大。那么解决方案是什么？就是 API 安全。想要深入了解如何确保您组织中的 API 安全最佳实践吗？请联系我们的中国合作伙伴咨询 consultant@gingxing.com。

API 安全是什么？

API 安全是一系列旨在保护组织 API 的最佳实践。除了基础设施安全参数外，公司还应在应用逻辑层面以编程方式保护 API。

应建立适当的 API 权限和规则，以确保只有目标受众能够使用允许的正确类型的 API。

API 安全是现代数字企业的关键组成部分。通过采取适当的安全措施，企业可以确保其 API 的安全性，并保护其传输的敏感数据免受未经授权的访问。

为什么 API 安全如此重要

由于软件行业广泛依赖 API，因此提供 API 的组织有必要使其更加安全和可信。在 2023 年 API 峰会上，Kong 的高级解决方案架构师 Ahmed Koshok 和 Traceable.ai 的渠道与全球贸易营销总监 Tyler Reynolds 讨论了 API 安全日益重要性和其最佳实践。

“我们当然还处于这个新兴的 API 安全领域的早期阶段，”Reynolds 说。“但考虑到 API 安全的未来发展，它将成为现代应用的基础。”

API 用于访问敏感信息，包括个人身份信息（PII）、财务数据和知识产权。目前，90%的网络流量通过某种 API 进行传输，其中许多流量都承载着敏感数据。任何未经授权的访问或数据泄露都可能给组织带来严重后果，包括法律责任、失去客户信任和声誉损害。此外，许多行业都受到关于保护敏感数据的监管要求的制约。

API 安全策略可以帮助组织遵守这些规定，避免罚款，并维护其声誉。

“我们不能不直面这个问题，”Reynolds 说。

识别和管理 API 安全风险

识别和管理 API 安全风险是维护安全可靠的 API 基础设施的关键方面。

以下是组织可以采取的一些步骤来最小化 API 安全风险：

• 盘点和管理您的 API。无论组织拥有十几个还是数百个公开可用的 API，都必须首先了解它们，以便正确保护和管理它们。API 蔓延和治理是所有云和遗留基础设施中普遍存在的问题，而人们无法保护他们不知道或不了解的东西。因此，将所有 API 记录在注册表中以定义其特性（如名称、用途、有效载荷、使用情况、访问权限、生效日期、退休日期和所有者）至关重要。这将避免忘记、从未记录或在主要项目之外开发的影子或孤立的 API——可能是通过合并、收购或测试或已弃用的版本。

• 监控和记录 API 活动。监控和记录 API 活动是识别潜在安全风险的重要方面。攻击者通常会反复探测 API 以寻找可以利用的漏洞或逻辑，因此实时监控对于攻击检测和响应至关重要。这种方法不需要预定义的策略、规则或攻击签名，因此它总是能够适应新的和不断发展的攻击。

“API 管理的两个维度是对 API 存在的了解和对其应用 API 治理。理想情况下，所有 API 都应该是已知和受管理的，”Koshok 说。

一旦组织对其 API 进行了盘点，Kong 会帮助其开发一个 360 度 API 安全管理框架，以了解这些 API、使用模式、依赖关系和应用程序流程，以及每个端点的风险级别。

常见的安全风险

在实施 API 时，组织应该意识到一些常见的 API 安全风险，如 OWASP API 安全前 10 名单中所述。

许多公开可用的 API 都存在认证和授权不足或缺失的严重问题。当 API 不执行认证（这在仅供内部使用的私有 API 中经常发生）或当认证因素（客户端知道、拥有或是的东西）容易被破解时，就会发生认证失效。由于 API 通常提供组织数据库的入口点，因此组织严格控制对其的访问至关重要。

API 容易受到网络和安全防御人员多年来一直在其网络和基于 Web 的应用程序中对抗的许多相同类型的攻击。以下攻击都不是新的，但它们可以很容易地针对 API 使用。

• 注入攻击发生在攻击者能够将恶意代码或命令插入程序中时，通常是在期望普通用户输入（如用户名或密码）的地方。SQL 注入是一种特定的注入攻击，使攻击者能够控制 SQL 数据库。

• 跨站脚本攻击（XSS）是一种注入攻击，当漏洞使攻击者能够将恶意脚本（通常是 JavaScript）插入到 Web 应用或网页的代码中时，就会发生这种攻击。

• 分布式拒绝服务（DDoS）攻击使网络、系统或网站无法供预期用户使用，通常是通过向其发送比其能够处理的更多流量来实现。API 端点是 DDoS 攻击目标不断增长列表中的一员。

• 中间人（MitM）攻击发生在攻击者拦截两个通信系统之间的流量，并相互冒充对方，在两个系统之间充当不可见的代理时。对于 API 来说，MitM 攻击可能发生在客户端（应用程序）和 API 之间，或者 API 和它的服务之间。

加密不足可能导致数据泄露和其他安全事件。这包括使用弱加密算法、未能加密敏感数据以及未实施 SSL/TLS 加密以保护传输中的数据。

管理安全风险与威胁

“这些泄露事件最可怕的地方在于，被利用的 API 完全是按照设计工作的，”Reynolds 分享道。“这并不是代码中的漏洞——而是简单地利用 API 的可预测性来使其执行开发者未打算执行的操作。”

这就是为什么无论你的 API 多么完善，你都需要将安全性放在首位。（我们可能听起来像是一个坏掉的唱片机，但这个步骤很容易被忽视。）API 安全不应该是事后才考虑的问题，也不应被视为别人的问题。组织在 API 不安全的情况下会失去很多，因此在开发 API 时就要将其安全性纳入其中，并实施强大的管理系统。

Reynolds 继续说道：“API 安全实际上是一个大数据问题。对于全面的 API 安全方法，你必须了解数据和身份，并深入了解应用程序的端到端业务逻辑。”

API 安全最关键的方面之一是实施身份验证和授权。这一步确保只有授权用户才能访问 API，并且他们的访问级别与其角色相匹配。在可行的情况下，使用基于可靠且经过验证的身份验证和授权机制的解决方案，如 OAuth2.0 和 OpenID Connect。

验证和授权

API 身份验证和授权是指验证客户端身份和控制对 API 资源的访问过程。身份验证是验证客户端是谁，而授权则是在身份验证后控制他们可以访问的内容。

为了确保 API 的安全性，需要实施身份验证和强大的授权控制。为了控制对 API 资源的访问，必须仔细且全面地识别所有相关用户和设备。这通常要求客户端应用程序在 API 调用中包含一个令牌，以便服务可以验证客户端的身份。

使用 OAuth 2.0、OpenID Connect 和 JSON Web 令牌（JWTs）等标准来验证 API 流量，并定义访问控制规则或授予类型，以确定哪些用户、组和角色可以访问特定的 API 资源。

安全模型的一致性

在内部和外部 API 上应用安全模型时保持一致性，有助于确保所有 API 都具备适当的身份验证和授权。这降低了 API 可能被没有适当凭据或权限的用户访问的风险。使用一致性的模型还使得审计和验证所有 API 是否已正确实施安全控制变得更加容易。

如果使用不同的模型，将增加整体管理 API 安全性的复杂性。采用一致性的方法，安全机制的更改只需在一个地方进行，而无需针对不同 API 分别重新实现。

总体而言，一致性有助于更好地执行策略、降低配置错误的可能性，并在添加更多 API 时简化大规模维护 API 安全性的工作。

建立安全通信

使用加密

所有网络流量都应该加密，特别是 API 请求和响应，因为它们可能包含敏感凭据和数据。所有 API 都应使用并要求使用 HTTPS。在可能的情况下，启用 HTTP 严格传输安全性（HSTS）比将 HTTP 流量重定向到 HTTPS 更好，因为 API 客户端可能不会按预期运行。

实施访问控制

实施 API 访问控制的第一步是确定你想要控制访问的资源。这可能是特定的端点、数据资源或 API 内的操作。

想要通过 API 允许第三方访问内部数据和系统的组织必须引入并测试控制措施来管理这些访问：谁、什么、何时，以及对数据访问、创建、更新和删除的检查——即零信任安全模型。

维护数据完整性

维护 API 数据完整性对于确保通过 API 传输的数据准确、完整和一致至关重要。

验证输入

永远不要假定 API 数据已经被正确清理或验证。在服务器端实现自己的数据清理和验证程序，以防止标准的注入漏洞和跨站请求伪造攻击。调试工具可以帮助检查 API 的数据流，并跟踪错误和异常情况。

包装错误响应

包装 API 的错误响应可以防止敏感的实现细节在面向客户端的响应中被暴露。

例如，通过返回通用的“404 Not Found”响应而不是框架特定的错误消息，底层技术堆栈保持不透明。这有助于避免可能帮助攻击者的无意信息泄露。包装还可以为客户端提供一个一致的错误响应格式，无论实际发生的错误是什么。客户端可以获得可操作的信息来优雅地处理错误，而不是解析意外的服务器错误消息。

最重要的是，错误包装使 API 能够遵守故障安全默认设置，即假设请求会失败并据此进行规划。API 可以在响应之前验证数据完整性，而不是通过未包装的错误暴露部分或损坏的内部状态。总体而言，包装 API 错误响应可以提高 API 消费者的安全性、可靠性和通信清晰度。

仅共享必要信息

一些 API 透露了太多信息，无论是通过 API 返回的大量多余数据，还是透露太多关于 API 端点信息的数据。这通常发生在 API 将数据过滤的任务留给用户界面而不是端点时。确保 API 只返回履行其功能所需的信息量。此外，在 API 级别实施数据访问控制，监控数据，如果响应包含机密数据，则进行模糊处理。

删除不应共享的信息。由于 API 本质上是开发人员的工具，因此它们通常包含密钥、密码和其他在公开之前应删除的信息。但有时这一步会被忽视。组织应将扫描工具纳入其 DevSecOps 流程中，以限制机密信息的意外泄露。

结论

API 为组织提供了无数的机会来改善和提供服务、吸引客户、提高生产力和利润——但前提是要安全地实施它们。在构建 API 时，请在开发过程中考虑质量和安全性，而不是等到事后才考虑。安全的 API 就是好 API！

想要深入了解如何确保您组织中的 API 安全最佳实践吗？请联系我们的中国合作伙伴咨询 consultant@gingxing.com。