如何阻止公司内部共享内部API密钥？

我们正在开发一项新服务-该服务可能会直接从用户设备上的应用程序中调用。这些应用程序将由组织中的多个开发团队开发并提供支持，所有这些均取决于我们提供的数据。

我们渴望确定哪些应用程序正在发送哪些请求，以便我们可以确定使用模式和负责的开发人员。（为避免疑问，用户身份验证是单独处理的。）

我们的解决方案是要求API密钥（每个应用程序一个）–然后我们需要开发团队的详细联系信息。

我们不想让API密钥成为麻烦，但是我们担心开发人员会将其共享给其他团队的同事，这意味着我们不再能够仅为一个应用程序识别流量。

我们如何激励开发人员不要在内部共享API密钥？

为了在团队之间共享这些密钥，团队需要彼此交谈，同意共享，然后共享。这需要时间。因此，如果团队可以更快，更轻松地向您请求API密钥，那么就没有共享的动力。

他们请求这些密钥的最简单方法是让您抢占它们。假设您知道所有其他需要API密钥的团队，请在将其提供服务之前创建它们并共享它们。

您还可以提供另一种激励措施：调试支持。当他们的工作与您的服务集成在一起时，如果事情无法正常运行，这些团队将需要您的帮助。这些API密钥使您可以跟踪其特定请求，从而帮助调试问题所在。因此，出售它作为密钥的原因，而不是“ 确定使用模式和负责的开发人员 ”，这听起来像是在监视他们的活动。

已经有了很好的答案，我只是想到了一种不同的方法，该方法可能对您不起作用。

与其发出要包含的密钥，不如要求请求的标头包含前端应用程序的名称，该名称应由前端应用程序的开发人员创建并格式化，就像Web浏览器一样。这样，前端仍然可以假装为其他应用程序，但是这样做没有任何好处，因此似乎不太可能。只需让前端标识自己并接受任何非空字符串即可。

简而言之：

第一：便利和好处；如有必要：摩擦和报警。

一些话

便利性：首先，使团队易于获得新的API密钥。例如，在启动新项目的公司程序中添加提醒，并提供易于使用的服务来请求新密钥，而无需提出理由。

好处：使自己的API密钥的使用对团队或产品所有者来说是一项好处。例如，根据该密钥提出一些有关应用程序使用情况的反馈。

摩擦：根据键的功能，您可能会产生摩擦，例如，如果将键链接到某应用定义的域（即，重用键不一定会提供对所有所需服务的访问权限）。

警务：最后，您可能需要预见一些警务措施。例如，您可以通过api键监视api函数的使用情况，并在给定的时间后建立基线，询问有关使用api部件的问题，这是基线所不希望的。或者，如果这不现实，则只需在公司项目审查清单中包括使用了有效密钥的验证即可。

备注：您可能需要非常清楚自己的API密钥政策：新的主要版本是否需要自己的API密钥？用叉子，或者如果一个应用程序拆分了怎么办？如果另一个团队负责，该怎么办...

通常，使开发人员“做正确的事”的最简单方法是使开发人员更容易做到这一点。

为此，我建议构建一个API密钥发布网页/站点。以其最简单的形式，它可能只是一个登录名（理想情况下与您的公司AD / LDAP绑定），而该页面仅要求输入应用程序名称并颁发密钥。

在一天结束时，您总是可以稍后撤消密钥，因此，您真正需要站点做的就是记录谁（用户名）请求密钥以及他们想使用该密钥什么（应用程序名称）以及所需的任何信息。稍后撤消密钥。

您可以使用票务系统执行类似的操作，但是到最后，我很容易将一个应用程序中的密钥复制并粘贴到另一个应用程序中，因此，申请新密钥必须非常容易，以免造成不良后果。行为。

主动。

识别可能的开发人员，并提前在安全通道中为他们提供唯一的API密钥。提供请求新API密钥的简便方法。提供一种方便新人请求新API密钥的方法。当新的实习生或雇用人员加入团队时，请给他们一张JIRA票证或类似的“请求API密钥”，并附带说明中的步骤。

跟踪已使用的API密钥，未使用的API密钥。如果Bob在项目中提交了工单，但没有使用过他的API密钥，那么他可能是借用了别人的。

有管理层的支持。别成为一个爱管闲事的南希，不要制定任何无关紧要的规则。从字面上说服管理层，这很重要，然后他们才可以说服团队这很重要。不要说服所有人。

最烦人，最容易暴政的建议是：警惕滥用行为，并在同一天进行镇压。最好是同一小时。不要说“坏顽皮的开发人员”，不要说“这是正确的步骤。” 如果他们重复执行此操作，请禁用误用的密钥。这给共享者和借用者都带来麻烦，并且共享者将来会说“不，请正确执行”。避免禁用实时项目中的密钥。

我们如何激励开发人员不要在内部共享API密钥？

• 通过自助服务应用程序注册生成密钥。
• 激活按键之前需要接触点。
• 并要求他们不要分享。（创建服务条款和/或告诉他们为什么不共享对他们更好。）

您还应该实施限速。这本身可能会阻止共享密钥。它在某种程度上保护您的系统免受滥用应用程序的侵害。（以及彻头彻尾的恶意攻击。）而且，它确保在可服务流量大量增加之前，您会有所了解。（希望给您时间来增加容量！）

并且，通过速率限制，当应用程序确实需要更高的限制时，它将打开一个对话框，其中已注册了密钥的POC。您有机会询问是否共享密钥，解释为什么这样做有害，等等，并且您可以在适当时提供其他密钥，而不是请求的速率限制更改。等等。

做事情的一种方法，尤其是如果团队使用共享的构建系统（或至少是足够通用的构建系统），是建立一个内部服务器，该服务器创建并发布API密钥（给与使用该产品的产品的一些基本信息） ）。然后，使用脚本从服务器获取每个构建或每个版本更新的新API密钥。让开发人员运行脚本来为其本地版本获取不同的密钥。（在可能的情况下，将其作为构建的一部分进行自动化，因此他们甚至不需要考虑它。）

这样可以告诉您是生产，质量保证还是开发人员开发的东西，以及问题是从哪个版本/版本开始的。

您要做的第一件事也是最好的事情是格式化密钥，以使它们以易于阅读的形式包含应用程序名称，并且如果您更改它就无法使用。

如果在团队使用错误的密钥时很明显，那么他们将努力不使用错误的密钥。

然后，定期使密钥过期。无论如何，您都应该这样做，并且当密钥即将到期时，您可以将新密钥发送给拥有它的团队。然后，使用密钥的团队将被激励以确保他们是拥有密钥的团队，以便他们可以在新密钥到期时获得新密钥。