容器，微服务和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下的软件的方式构建的，那么API代表的函数将会运行，并且会发生一些事情。 信息可能会返回给不应该被允许使用的人，也可能被更改。 即使是具有错误格式的“垃圾”请求也可能会浪费处理能力，为API和使用它的任何应用程序创造机会。

许多用户期望通过使用位于API和可能访问它们的应用程序之间的目录或管理功能来解决安全API，因此仅提供间接和策略控制的访问。 这种方法的问题是通常不会使API无法访问，除非通过管理工具; API仍然是一个网络寻址的实体，它可以通过扫描IP地址来定位。

实现安全API

最有效的API安全性最佳实践从多区域网络开始。 应用程序应在安全区域或沙箱内运行，并仅向外界公开几个服务地址。 不能向所有人提供的API应该托管在此安全区域内。 一些托管架构，包括Docker容器，自然提供安全区域，它们可以通过现在可用的大多数私人软件定义的网络架构来实现。 通过建立多区域网络，安全的API问题将大大降低。

实现安全API最佳实践的下一步是网络连接控制。 不是通过管理员调解对API的访问，而是通过网络策略管理来控制API的地址。 这种方法测试消息的源IP地址，例如，只将消息从适当的用户传递到API。 仍然有一些绕过这种保护的方法，但它提供了最好的保证，API将不被未经授权的个人访问; 它还提供防止拒绝服务攻击您的API的保护。 对建立安全区域的网络应用网络连接控制是最简单的，因为可以容易地识别区域内流量。 因此，只有暴露在区域外使用的API才能得到保护。

网络连接控制可以清除入侵者，但与公司内部广泛使用的应用程序相关的API可能仍然可以由不需要的人员或API代表的信息的权限进行访问。 API管理可以“认证”用户，在某些实现中，它也可以实际重定向流量，因此API消息只能来自API管理器，而不是直接从用户的信息来源。 添加到网络连接控制，这大大有助于实现安全的API最佳实践。

最后一步是加密。 如果对API的消息必须加密，那么直接访问API的尝试将不会通过加密测试，并将被丢弃。 在大多数情况下，最好是由API的用户直接生成加密，而不是API管理器。 但是请确保足够的消息清楚地允许API管理员应用访问策略。 通常，IP报头是足够的，但是在某些情况下，也可以使用较高层报头进行认证。 如果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的请求的延迟。

监控的具体实现将因平台而异，但要特别注意隐含地跟踪应用程序中的API请求，因为可能需要尽早尽快地识别问题。

如果API性能很差，并且在改善API的可用性上能做的很有限，那么将API请求从面向客户端的代码中移除，可以帮助缓解问题。更普遍的做法是，采用异步处理和数据管理。

了解每个API请求的平均延迟对于确定数据的缓存时长，哪些数据应该长期存储，甚至哪些关键请求应该及时响应都非常有帮助。

最终，API性能监控与任何其他类型的应用程序监控没有什么不同。 使用API的区别是应用程序如何应用它们。 在任何应用程序中都有很多依赖的部分，而这种依赖意味着要注意API在应用程序中是否能有效得运行。

通过优化数据库查询和缓存耗时操作等一系列措施，可以大大提高API的整体运行状况。

英文原文链接：

http://searchcloudapplications.techtarget.com/ehandbook/Sound-application-development-rests-with-secure-APIs-in-the-cloud