如何知道谁在使用您的API密钥？

一旦您的安全协议和命令到位，您就需要了解如何监控 API 密钥的使用情况，以确保不良行为者不会利用这一点。

然而，确定谁在使用您的密钥、了解授权用户的 API 值以及确定要监控的正确指标仍存在挑战。您可以使用适当的分析来解决这些问题，但由于需要消化的信息太多，您可能会发现自己不知如何解读这些信息。

本指南将解答这些复杂的问题，并让您全面了解如何监控 API。毕竟，调查数据显示，35%的组织关注 API 性能。

什么是 API 监控？

API 监控是一种观察应用程序中的 API 密钥的方法，以深入了解其性能、可用性和响应能力，从而评估 API 的功能。它是一种网络安全最佳实践，可帮助组织找到任何中断或执行不佳的 API 调用，从而导致应用程序、网站或相邻服务故障，从而对用户体验产生负面影响。

API 监控通过分析并提供对 API 问题的可见性，直接从 API 测试和监控解决方案中识别问题。API 密钥监控器通过警报和异常检测快速促进问题识别、预防和解决问题，防止问题发展成更大的问题。

异常是与正常行为不同的矛盾。例如，如果您使用银行应用程序，每月从储蓄中提取 100 美元，而某个月提取了 10,000 美元，这将被视为异常。

API 监控工具利用人工智能的一个子集，即机器学习 (ML) 来检测此类异常。ML 将利用时间序列分析，即以线性进程记录的与时间相关的观察结果。这就是 API 监控确定异常机制是否触发请求的方式，这可能表示存在机器人或不良行为者活动。

之后，软件将向授权用户发出警报。警报是监控系统的一种反应性解决方案，当 API 检查失败时触发。

为何应监控 API 密钥的使用情况

API 监控可让您确定 API 的可用性、行为和功能正确性。API 密钥是您的应用程序或网站的白细胞。它们决定谁可以访问 API。因此，如果管理不当，它们的故障可能会导致整个系统故障。

如果您不清楚幕后发生了什么，就会无意中在组织中造成盲点，危及业务运营的关键要素。如果您的企业以任何方式使用 API 或将其作为服务提供，则必须确保它们可用、响应迅速且安全。

API 监控流程

API 监控软件根据预定参数或从多个位置触发 API，并记录性能时间和响应详细信息。API 监控过程包括以下步骤：

配置——此步骤主要定义 API 的参数，例如 HTTP 方法、URL、请求详细信息、位置和预期值。这将为受监控的 API 设置框架。
运行– 接下来，软件会使用预配置的参数定期从指定位置触发 API。之后，系统会记录这些结果。
警报– 应用程序将结果与配置步骤中的预期值进行交叉检查。如果结果与预期值不匹配，系统将向用户发送警报。
报告——最后一步是系统生成有关一定时期内的响应时间和可用性的报告，以供长期分析。

API 密钥使用需要考虑的指标

您应该关注某些指标来确定您的 API 是否为其用户带来了价值，并避免关注虚荣指标。

每分钟请求数 (RPM)

作为 API 指标，RPM 很简单。它指的是测量 API 每分钟处理的请求数。此数字会根据日期和时间而变化，因此其主要用途是建立请求数的基准。

失败率

了解失败的次数至关重要。API 技术并非万无一失，与任何其他软件一样，它可能会失败。如果您知道您的 API 可能会失败，那么决定采取何种行动就更容易了。您将能够确定替代方案是否最佳，或者使用其他 API 服务是否是正确的选择。

延迟

网络延迟以毫秒为单位，是请求或数据从源头到目的地所需的时间。目标是让延迟尽可能接近零。延迟越高，用户的负面体验就越严重。

API 正常运行时间

API 正常运行时间是根据服务器在特定时间段内可用的时间窗口计算得出的。此指标可让您检查请求是否可以成功发送到 API 端点并获得具有预期 HTTP 状态代码的响应。

CPU 使用率和内存

衡量 API 对服务器的影响。确定这种影响的两个重要指标是 CPU 和内存使用率。高 CPU 使用率可能意味着服务器容易超载，从而产生瓶颈，对用户体验产生负面影响。

内存使用情况可让您确定资源使用量。了解这些指标可以帮助您确定是否需要降级或升级机器以减轻压力，从而避免瓶颈。

首次 Hello World (TTFHW) 的时间

开发人员将熟悉 TTFHW 的概念，它是新编程语言中的第一个表达式，它将输出文本“hello world”。TTFHW 指的是用户自登陆您的网页以来进行初始 API 交易所需的时间。

确保您的 API 有价值

过去，API 是负责跨多个系统集成和交换数据的中间件。API 工作是 IT 部门的产物，因此用于对 API 进行分类的分类法（分层框架）不直观且技术性强。这阻碍了业务利益相关者参与 API 优先级排序和设计。

在当今的环境下，行业领先的企业正在使用业务和 IT 部门都能理解的通用语言来定义其 API 分类法。关键在于区分直接服务于业务的 API 和支持技术功能的 API。精简的分类法可以显著减少 API 分析时间，并提高采用率和价值实现率。

适当的分类法使业务人员和 IT 人员能够讨论哪些 API 直接引导客户体验（业务），哪些 API 是允许提供这些体验的基础设施的一部分（技术）。换句话说，更有效地对 API 进行分类可以更广泛地了解 API 是否为客户体验提供了价值。

现在我们已经介绍了 API 监控，让我们深入研究与确定谁在使用您的密钥相关的一些挑战，以及基于上述指标防止不良行为者访问您的 API 的最佳实践。

API 安全的挑战

API 可能使用类似的框架和模型，但这并不能改变数据协议总是不同的事实。这就是为什么有效的 API 安全性需要转换不同协议使用的各种数据格式和语言以及每个请求的意图。然而，由于以下原因，这说起来容易做起来难。

API 是独一无二的

API 保护就是要理解 API 背后的设计原理。这需要整理和理解由人为变化和技术复杂性形成的排列和代码层。

API 的通用基础框架包括 XML 和 gRPC。但是，我们无法了解开发人员如何设计任何给定的应用程序。因此，标记、数据的类型以及应用程序逻辑本身都会有所不同。

API 中的代码层通常很强大。解析器需要大量数据来解码应用程序设计。挑战在于，您可能会在某一层中找到 JSON，但在另一层中找到不同的代码迭代。

服务 API 管理

很多软件即服务（SaaS）平台仅通过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。API 千差万别，且与人类的变化相结合，使其每天都变得更加复杂。组织内的开发人员和 IT 部门应该考虑这些障碍，因为它们使识别谁使用 API 密钥变得更加困难。

恶意攻击者如何窃取您的 API 密钥

意识到监控 API 密钥安全性的挑战是一回事，但了解不良行为者如何窃取您的密钥又是另一回事。让我们介绍一些最常见的攻击。根据数据，91%的企业都经历过某种形式的网络攻击。

DDoS 攻击

分布式拒绝服务 (DDoS) 攻击是指黑客试图通过淹没目标系统的带宽或在每个请求中发送大量信息来压垮 API 内存。您可以通过了解 API 的正常内存使用情况或根据 API 监控工具接收表示异常（请求数量大于正常数量）的警报来识别此类攻击。

MITM 攻击

中间人 (MITM) 攻击会秘密更改、中继和拦截双方之间的请求和消息，以窃取敏感信息。恶意攻击者通过拦截向 HTTP 标头和用户发出 API 的会话令牌成为中间人。一旦黑客获得该令牌，他们就可以访问用户帐户并窃取敏感信息。API 监控工具可以检测恶意攻击者并向授权用户发出警报。

注入攻击

注入攻击通常发生在运行开发代码不够完善的应用程序上。为了获得访问权限，黑客会将恶意代码注入软件（例如 SQL 注入和跨站点脚本）。双因素身份验证器（使用两个密码才能获得访问权限）和加密可以阻止恶意行为者注入恶意代码。

通知的力量

如果您没有收到警报形式的通知，那么它们就不是什么好事。您的公司应该使用 API 监控平台，当有新密钥创建时，该平台可以在第三方渠道（例如电子邮件或 Slack）中 ping 您，或者提供有关谁在使用您的 API 密钥的更新信息。

文章来源：How Do You Know Who’s Using Your API Keys?