商户密钥和api密钥_安全存储API密钥的最佳做法

商户密钥和api密钥

by Bruno Pedro

布鲁诺·佩德罗(Bruno Pedro)

安全存储API密钥的最佳做法 (Best practices for securely storing API keys)

In the past, I’ve seen many people use Git repositories to store sensitive information related to their projects.

过去，我已经看到许多人使用Git存储库来存储与其项目相关的敏感信息。

Lately, I’ve been seeing some people announce that they’re storing API keys on their private GitHub repositories. I’m writing this article because people should understand the risks of storing API keys with your code.

最近，我一直看到有人宣布他们正在将API密钥存储在其私有GitHub存储库中。 我写这篇文章是因为人们应该理解将API密钥与代码存储在一起的风险。

This article is not intended to be a permanent solution to the problems you might have with storing API keys. Instead, it’s my own analysis of the problem and my suggestions on how to fix it.

本文并不打算永久解决您存储API密钥时遇到的问题。 相反，这是我自己对问题的分析以及有关如何解决问题的建议。

So, what exactly is the problem with storing sensitive information near your code on a Git repository?

那么，将敏感信息存储在Git存储库中的代码附近到底是什么问题呢？

为什么不应该将API密钥存储在Git存储库中 (Why you shouldn’t store API keys on Git repositories)

Storing API Keys, or any other sensitive information, on a git repository is something to be avoided at all costs. Even if the repository is private, you should not see it as a safe place to store sensitive information.

不惜一切代价避免在git存储库中存储API密钥或任何其他敏感信息。 即使存储库是私有的，您也不应将其视为存储敏感信息的安全场所。

Let’s start by looking at why it’s a bad idea to store API keys on public git repositories.

让我们先来看一下为什么将API密钥存储在公共 git存储库上是个坏主意。

By nature, a public git repository can be accessed by anyone.

从本质git ，任何人都可以访问公共git存储库。

In other words, anyone with an Internet connection can access the contents of a public git repository. Not only that, but they can also browse all the code inside the repository and possibly even run it. If you store an API key on a public repository, you are publishing in the open so that anyone can see it.

换句话说，任何具有Internet连接的人都可以访问公共git存储库的内容。 不仅如此，他们还可以浏览存储库中的所有代码，甚至可以运行它。 如果将API密钥存储在公共存储库中，那么您将公开发布，以便任何人都可以看到它。

A recent search for client_secret on GitHub revealed that there are more than one 30,000 commits that potentially expose an API key and secret. In some cases, you only copy and paste the code to immediately access the API.

最近在GitHub上对client_secret的搜索显示，有超过30,000次提交可能暴露了API密钥和机密。 在某些情况下，您仅复制和粘贴代码即可立即访问API。

This problem is becoming so important that some companies invest in resources to make sure that there aren’t any leaked API keys and secrets.

这个问题变得越来越重要，以至于有些公司在资源上进行投资以确保没有泄漏的API密钥和机密。

Last year, Slack started to search for exposed API tokens and invalidate them proactively. This action prevents malicious access to Slack’s accounts but can’t possibly find all the leaked tokens.

去年，Slack开始搜索公开的API令牌并使它们主动失效。 此操作可以防止对Slack帐户的恶意访问，但可能无法找到所有泄漏的令牌。

So, this is happening on public Git repositories. What about the private ones? Why is that an issue?

因此，这是在公共Git存储库上发生的。 那私人的呢？ 为什么这是一个问题？

Private Git repositories hosted on services such as GitHub, GitLab, and Bitbucket are exposed to a different type of risk. When you integrate a third-party application with one of the services mentioned, you may be opening your private repositories to those third parties. Those applications will be able to access your private repositories and read the information contained within.

托管在GitHub，GitLab和Bitbucket等服务上的Private Git存储库面临另一种风险。 当您将第三方应用程序与所提到的服务之一集成时，您可能正在向这些第三方打开私有存储库。 这些应用程序将能够访问您的私有存储库并阅读其中包含的信息。

While that alone doesn’t create a risk, imagine if one of those applications becomes vulnerable to attackers. By getting unauthorized access to one of those third-party applications, attackers might gain access to your sensitive data, including API keys and secrets.

尽管仅此一项并不会带来风险，但请想象这些应用程序之一是否容易受到攻击者的攻击。 通过未经授权访问那些第三方应用程序之一，攻击者可能会访问您的敏感数据，包括API密钥和机密。

那么，API密钥应该存储在哪里？ (So, where should API keys be stored?)

There are many alternatives for securely storing API keys and secrets. Some of them let you use your Git repository and encrypt the sensitive data. Other tools are more sophisticated and decrypt sensitive information as part of a deploy workflow. Let’s look at some of the available solutions.

有许多安全地存储API密钥和机密的方法。 其中一些可以让您使用Git存储库并加密敏感数据。 其他工具更复杂，并且在部署工作流程中解密敏感信息。 让我们看一些可用的解决方案。

git-remote-gcrypt (git-remote-gcrypt)

The first solution lets you encrypt a whole Git repository. git-remote-gcrypt does that by adding functionality to Git remote helpers so that a new encrypted transport layer becomes available. Users only have to set up a new encrypted remote and push code into it.

第一种解决方案使您可以加密整个Git存储库。 git-remote-gcrypt通过向Git远程助手添加功能来做到这一点，从而使新的加密传输层可用。 用户只需要设置一个新的加密遥控器并将代码推送到其中即可。

Read on if you’re looking for a more fine-grained solution that lets you encrypt individual files.

如果您正在寻找更细粒度的解决方案来加密单个文件，请继续阅读。

git-secret (git-secret)

git-secret is a tool that works on your local machine and encrypts specific files before you push them to your repository. Behind the scenes, git-secret is a shell script that uses GNU Privacy Guard (GPG) to encrypt and decrypt files that might have sensitive information.

git-secret是一种可在本地计算机上运行的工具，可在将特定文件推送到存储库之前对其进行加密。 在幕后， git-secret是一个Shell脚本，它使用GNU Privacy Guard( GPG )加密和解密可能包含敏感信息的文件。

git-crypt (git-crypt)

Another solution is git-crypt. It is very similar to git-secret in the way it operates, but it has some interesting differences.

另一个解决方案是git-crypt 。 它的操作方式与git-secret非常相似，但有一些有趣的区别。

The first thing to notice about git-crypt is that it is a binary executable and not a shell script, as git-secret is. Being a binary executable means that to use it you first have to compile it, or you need to find a binary distribution for your machine.

关于git-crypt的第一件事是，它是一个二进制可执行文件，而不是像git-secret一样的Shell脚本。 作为二进制可执行文件，意味着要使用它，您首先必须对其进行编译，或者您需要为计算机找到二进制发行版。

If you’re using a Mac you’re lucky because HomeBrew offers a git-crypt ready-to-install package. All you have to do is run brew install git-crypt on a terminal.

如果您使用的是Mac，那么您会很幸运，因为HomeBrew提供了一个git-crypt即可安装的软件包。 您要做的就是在终端上运行brew install git-crypt 。

黑盒子 (BlackBox)

BlackBox is a tool created by Stack Overflow. This is the company behind popular Q&A communities such as Stack Overflow itself, Server Fault, and Super User. BlackBox is a robust tool as it works with Git as well as other version control systems like Mercurial, and Subversion.

BlackBox是由Stack Overflow创建的工具。 这是受欢迎的问答社区(例如Stack Overflow本身，Server Fault和Super User)背后的公司。 BlackBox是一款强大的工具，可与Git以及Mercurial和Subversion等其他版本控制系统一起使用。

It also supports the encryption of small strings and not only entire files. It does that when working with Puppet and uses Puppet’s Hiera, a key-value lookup tool for configuration data.

它还支持对小字符串进行加密，而不仅限于整个文件。 在使用Puppet并使用Puppet的Hiera (用于配置数据的键值查找工具)时，它会执行此操作。

Having the ability to encrypt and decrypt individual strings makes BlackBox a great solution for securing API keys and secrets.

BlackBox具有加密和解密单个字符串的能力，使它成为保护API密钥和机密的绝佳解决方案。

Heroku配置和配置变量 (Heroku Configuration and Config Vars)

If you’re working with Heroku you should not store any sensitive information such as API keys and secrets on your Git repositories. Heroku offers a solution that lets you set configuration variables.

如果使用Heroku ，则不应在Git存储库中存储任何敏感信息，例如API密钥和机密。 Heroku提供了一种解决方案，可让您设置配置变量 。

Your application can then access the contents of those configuration variables during runtime by accessing the corresponding environment variables. Even though the values are not encrypted, this solution lets you avoid using your Git repository for storing API keys.

然后，您的应用程序可以在运行时通过访问相应的环境变量来访问那些配置变量的内容。 即使未加密值，此解决方案也使您避免使用Git存储库来存储API密钥。

Dokku, an Open Source solution like Heroku, offers the same capabilities.

像Heroku这样的开源解决方案Dokku提供了相同的功能。

Docker的秘密 (Docker secrets)

At the end of the spectrum of possible solutions is Docker secrets. This solution was introduced by Docker in February 2017. It has gained popularity ever since.

在可能解决方案的最后是Docker的秘密 。 此解决方案由Docker在2017年2月推出 。此后一直受到欢迎。

Docker secrets lets you define encrypted variables and makes them available to specific services during runtime. Secrets are encrypted both during transit and at rest.

Docker机密可让您定义加密变量，并使它们在运行时可用于特定服务。 机密在运输过程中和休息时都会被加密。

This approach makes Docker secrets the perfect solution for storing and using API keys and secrets in a secure and encrypted way.

这种方法使Docker机密成为以安全和加密方式存储和使用API​​密钥和机密的完美解决方案。

摘要 (Summary)

By now you should be aware of the dangers of storing sensitive information such as API keys and secrets on public and private Git repositories.

到目前为止，您应该意识到在公共和私有Git存储库上存储敏感信息(例如API密钥和机密)的危险。

Understanding the potential ways in which your repositories might be exposed is key to assessing and mitigating the risks associated with information leaks.

了解评估存储库的潜在方式是评估和减轻与信息泄漏相关的风险的关键。

This article also proposes a few different solutions that let you encrypt API keys and secrets so that you can securely use your code repositories.

本文还提出了几种不同的解决方案，可让您加密API密钥和机密，以便安全地使用代码存储库。

I’m sure there are more solutions out there that can help you achieve the same results.

我相信还有更多解决方案可以帮助您达到相同的结果。

翻译自: https://www.freecodecamp.org/news/how-to-securely-store-api-keys-4ff3ea19ebda/

商户密钥和api密钥