API安全：将技术控制与业务风险保持一致

应用程序编程接口（API）是业务流程自动化和高效公司间协作的基础，但它们也带来了新的独特安全风险。

尽管有强大的实施模式，许多组织仍依赖过时的做法，例如为外部API使用静态的、几十年前的密码。这带来了经典的困境：改善API安全的有形成本与抽象的网络风险之间的对比。因此，将技术改进与企业业务风险保持一致是为这些举措获得资金的关键，本文将解释其机制。

**理解企业安全风险**

在启动任何工程工作之前，组织必须优先考虑其安全风险。风险矩阵对此任务至关重要，它基于两个维度可视化和排列风险：

严重性：事件或意外的潜在后果（例如，30万美元的损失）。

可能性：风险实现的概率（例如，10年一次）。

严重性有许多方面，从直接收入损失和罚款到无法执行工作的员工。严重性还涵盖没有直接财务影响的方面，包括对品牌声誉的潜在影响、监管机构干预或数据隐私办公室的行动。严重性评估高度依赖于组织的背景，如行业部门、财务稳定性和规模。

**将风险矩阵应用于API安全**

增强API安全的令人信服的商业案例始于将风险映射到组织的风险矩阵上。API需要根据其数据或业务目的进行个别或分类评级。对于严重性维度，重点是API妥协的潜在后果。攻击者会获得医院的患者数据或火箭建造计划的访问权限，还是仅仅获得在线网店的图片？他们能否启动资金转移或干扰火车或空中交通控制系统？

然而，可能性维度更具挑战性。如果一个API今年发生了一次事件，两年前又发生了一次，没有人会现实地争议"经常"评级。然而，通常（幸运的是）没有支持的历史数据。然后，评级可能引发争论。有些人可能会争辩说，如果从未发生过任何事情，可能性必须无限期地为零——这显然是有缺陷的推理。

这里的实用方法不是看个别API，而是评估底层API安全模式。模式"无定期密钥轮换的访问密钥"可能触发"经常"的可能性评级，而将VPN隧道与OAuth结合可能被评为"很少"。

**可接受和不可接受的风险**

如果成本效益分析显示积极的投资回报率（ROI），为API安全改进寻找资金是直接的。

想象一个支付API，估计违约可能性为每五年一次，每次违约造成50万美元的损失。在这种情况下，如果违约可能性降低到50年一次，每年花费1万美元来实施、监控和维护更安全的API会带来明显的财务效益。

不幸的是，这样令人信服的商业案例很少见。大多数网络安全项目遵循不同的逻辑：将风险水平从不可接受降低到可接受。风险矩阵在此背景下正式化了组织的风险偏好，有助于区分可接受和不可接受的风险。

API A具有"高"严重性和"确定"可能性，导致分类为"黑色"。这对此企业来说是不可接受的高风险，需要改进此API的安全性。然而，API B是"绿色"的，在组织的风险偏好范围内。API C是"红色"的。高级管理层必须正式接受风险或投资改进此API的安全性。

**如何降低API安全风险**

有两种策略来解决高API相关风险：减少API相关安全事件的潜在影响和减少此类事件的可能性。减少可能性是一种对应于在风险矩阵中"向上移动"的策略。

一个选择是通过用证书替换访问密钥或用托管工作负载身份替换证书来改进身份验证机制。加强网络级安全，如通过VPN隧道路由到API的流量，是另一个有效选择。

运营改进是减少API相关安全事件可能性的非技术但有效的替代方案。限制谁可以访问证书或为安全关键的API更改实施四眼原则是运营调整的两个例子。这些措施减少了故意和意外错误配置的风险。

或者，组织可以在风险矩阵中向左移动，从而通过限制事件的潜在影响来降低风险。在此背景下可以采用各种策略。例如，支付API可以监控异常，如外出支付突然增加50%，并暂时停止进一步支付以允许调查。其他潜在措施包括从API中删除敏感个人数据或甚至所有个人识别数据——两者都降低了API的风险评级，对于数据保护和隐私是主要安全关注点的API。

**API安全和安全软件工程**

个别评估适用于大型项目和遗留API。然而，持久的成功取决于从一开始就设计具有适当安全性的API。基于迄今为止讨论的概念，两个关键的准备行动是为开发人员清楚定义指令的基础。

第一个准备行动是为API的关键性定义直接规则。例如，如果API为个别客户检索销售数据，并对每分钟超过10个请求进行自动限制，其事件严重性将分类为"中等"。如果API提供完整的客户列表和完整的CRM数据，事件严重性是"高"。

第二个准备前提是评估事件或违约可能性的安全模式。例如，公司可能将带轮换的访问密钥评为"经常"，证书评为"不频繁"，带相互传输层安全（mTLS）的VPN隧道评为"很少"。以"橙色"风险偏好，个别客户数据的API必须实施带轮换的访问密钥。静态密码将不够，VPN隧道将是过度投资。这种方法为开发人员提供了明确的规则。

**结论**

在当今的数字环境中，工程师和安全专家需要了解的不仅仅是API安全的技术方面。他们必须将组织的风险偏好与当前或设想的API安全模式的风险保持一致。

在这项努力中，风险矩阵是每个工程师和安全专家必须了解并理解如何应用的关键工具。