对培育市场创新来说，安全管理 API 技术至关重要

Web Services 是一种以 API 为基础的相对标准的方法。API 直接连接底层数据，以便某个公司网站、应用或内部系统的能力，能够被另一家公司或多个实体访问和使用。这种方法依据实时创新的概念，提供了杰出的市场投放速度，但它需要在如何保护和管理 API 方面采用全新的标准，被具备在 B2B 企业网关层面进行组织机构间通讯的特质。

APIs 如何支持业务模式创新？最显而易见的方法是利用成熟 API 平台的 Mashup 来实现（例如 Google 地图和基于位置的服务）。另外，或许还有不那么明显的方法，支持企业创建少量超级 API（uber-APIs），以便让企业级应用执行全新的功能，例如通过新渠道扩展市场覆盖。由企业级 API 衍生出的 Mashup 中，最知名的两个例子是 Salesforce.com 和 DocuSign。

无论何种情况下，在各个技术平台和领域实体中对 API 进行管理、治理和安全保护，都必须遵循基本相同的策略，而且必须考虑与相应应用通信相关的连通性和传输协议。当组织机构需要通过云或移动平台分享应用和数据的时候，API 的好处就愈加显著了。然而，在公共 / 私有云环境中通过 API 调用公司数据，却又未能在恰当的地方对身份、访问、漏洞和风险进行合适地管理，将会把这些数据源暴露给潜在的威胁（参考如何使用统一服务网关来管理和保护API 。）

以下是一些技术驱动创新的例子，它们都要求最严格的自动化API 安全性和遵从性标准：

零售市场服务：近场通信（NFC）让智能手机能够通过RFID 与物理产品进行交互。例如，可口可乐可以在飞机上的过道中生成一份奖励券，发放给某位点击智能手机上NFC 功能的消费者。对这种交互进行个性化定制的能力，依赖于顾客资料的许可和安全认证——该案例以及其他许多NFC 功能都将通过安全管理的API 来实现；此外，零售渠道中部署的NFC API 将需要遵循支付卡行业数据安全标准（PCI DSS）。

数字视频服务：WebRTC（实时通信）是W3C 开发的一套新兴开源视频标准。WebRTC 让浏览器应用能够在相互之间进行视频聊天、语音通话和点对点文件共享，而无需使用第三方媒体播放器或插件。这些视频应用对已有的实时协作和通信标准（例如WebEx 和Windows 媒体播放器）造成了威胁；另外，它们所要求的安全传输和认证由API 负责完成。对基于会议的应用来说，API 将必须支持经过恰当授权的使用和复用、通过职责分割实现的特许执行通信，以及实时代码控制。

电子医疗记录服务：源自政府要求和业务需求的EMR 广为世人所知晓；而把医疗数据普遍进行数字化，还将为基于API 的服务创造机遇。例如，API 能够与个人医疗档案交互，以提升医疗服务的业务和服务。例如，一个排程应用，将把病人的个人医疗需求与可用的服务和专家进行匹配；或者一个SMS 应用，将提醒病人查看新的信息或是检查结果已生成。与EMR 交互的API 必须遵循数据隐私和法规要求的最高标准。

金融云服务：现在，60% 以上的证券和商品交易都包含被称为高频交易（HFT）的部分；对这个行业来说，依据交易量、成功算法、按量定价和比较分析，得到的分析数据是宝贵的信息集。例如，一家规模庞大的机构中，可能有多达1 万名专业员工在使用HFT 技术，这就要求同一时刻对同一数据的可见性（能够同时访问相同数据）。这一类型的数据即服务平台的终极价值，是对未来交易机会的模型风险管理分析。因此API 必须像其他金融调控技术一样，能够有效地保护底层数据。

数据分享加密服务：在中端市场和大型企业中不断增长的趋势之一，是将其IT 基础设施的特定部分交给一家公有云服务提供者，例如亚马逊Web 服务（AWS）。企业计算、存储和网络集群与亚马逊弹性云（EC2）之间的交互，是通过企业与EC2 各自API 之间进行通信来完成的。然而，底层拓扑存储往往采用Hadoop 这样的开放标准，因此并不总是与某个企业自有的数据存储或数据运动标准一致。为此，企业API 网关需要在云端协调适当可接受的使用方法和数据加密标准，就像该服务是由企业自身代理的一样。

API 业务敏捷度是管理和安全两方面都会涉及的问题。API 管理者必须考虑可以将多少 API 治理自动化，以减少潜在的编码错误。另一方面，安全性问题与治理政策、数据保护和遵从性相关，依从所有必要的缓和措施，以实现最优的业务敏捷度。（想要进一步了解深度分析，请参阅现实中的 API 管理与挑战）

数据保护：开发者使用 API 对公司文件进行的访问如果未经授权，那么就将会带来破坏数据完整性的危险。不管这种行为出自恶意还是偶然，一旦有人通过某个 API 访问公司数据，都有可能造成该数据的变更，从而造成企业在金融交易等数据完整性方面的审计违规。

合规遵守情况：让我们看一个来自某全球制造商的例子。该制造商开发了一套订购系统，并信任该系统把收到的客户订单数额报告给第三方应用开发者。这样，该制造商就把自己的财务报表准确性置于潜在的危险之中。在小“c”方面——对内部控制和 API 治理的合规性——公司面对这样的风险：其 ERP 系统或许受到侵害，进而影响数据完整性和可用性。在大“C”方面（外部压力的合规性），订购系统缺乏控制和 API 治理，将会导致公司违反萨班斯法案——该法案针对内部控制，旨在确保财务审计的准确性。

风险缓解：让我们继续以上面的全球制造商为例，对于谁能够访问后端 ERP 系统以及正在运行的 API 版本是否正确的不确定性，将会对内部控制造成严重破坏。例如，如果某个分销商能够通过 API 访问采购订单并变更其日期——在内部控制中，理论上来说这是严格禁止的行为——那么控制就是有缺陷的。同样的风险会在这个控制过程中展现它自己。缺乏恰当治理的 API，将破坏税务数据的完整性。

因此，恰当地治理，涉及到开发一系列 API 控制对象——它们基于生命周期和相关因素，例如关键的利益干系人涉及到业务和 IT 的角色（就像用于服务的 ITIL 和用于流程的 COBIT）。任何接触 API 并受制于合规设计的流程，例如内部或数据隐私控制，应该满足以下三条关键的治理目标：

1. 应该对 API 生命周期进行控制，这样只有得到许可的版本才会进入到产品中：在规划阶段，开发和测试阶段，转化为产品并最终退出市场。
2. 关键的利益干系人，例如业务线主管、IT 经理、信息安全官和合规审计师都应该能够动态地看到 API 的当前状态。应该永远确保他们看到的，是处于恰当的生命周期环境中的正确的版本。
3. 应该基于验证和授权流程对 API 进行控制，以保护企业 IT 资产，避免误用、对可用性的威胁或是侵犯隐私等问题，并确保监控和节流的治理任务能够得到履行。

关于作者

Atchison Frazer是一位网络和服务方面的战略专家，其企业市场管理经验涵盖从初创企业 Gnodal、ServGate 到业界龙头 Cisco、HP 等企业客户。

查看英文原文： Securely Managed API Technologies Key to Fostering Market Innovation