Firebase 功能第二代 - 运行时隐私和安全

Question

我刚刚从第一代 Firebase 功能迁移到第二代。 在本文档中，写到：GCP 不保证以 env 变量形式存储的数据的纯粹安全性。 文章还推荐使用Secret Manager ，它比 Firestore 的读取操作要贵得多。 这也意味着谷歌不保证 Firebase 函数运行时环境变量的安全性。 我在 Firebase 函数的第二代中使用 Node.js 16 运行时。

第二代 Firebase 函数的 Node.js 16 运行时环境是否足够安全，可以在运行时使用敏感数据？ 我计划在第二代 Firebase 函数的 Node.js 16 运行时中从 Firestore 读取最敏感的数据，并在不将其记录在我的代码中的情况下使用它。 但是，如果像 env 变量这样的安全数据可以记录在某种运行时（上述文档中未指定），那么找出并处理此类安全异常会让我感到沮丧。 所以我想确保从第二代 Firebase Functions 的 Node.js 16 运行时中检索到的数据是完全安全的。 不幸的是，我找不到任何适当的文档来指定 Node.js 16 运行时的这种安全保证。

+正如评论中提到的@Doug， completely safe在上下文中太模棱两可了。 因此，这是问题中安全性的详细信息：

环境变量可用于 function 配置，但不建议将其用作存储机密信息（例如数据库凭据或 API 密钥）的方式。 这些更敏感的值应该存储在您的源代码和外部环境变量之外。 某些执行环境或使用某些框架会导致环境变量的内容被发送到日志中，并且不建议将敏感凭据存储在 YAML 文件、部署脚本或源代码控制下。 对于存储机密，我们建议您查看机密管理的最佳实践。 请注意，Cloud KMS 没有特定于 Cloud Functions 的集成。

上下文中的安全性如下：考虑到官方文档的上述评论，我想确保我从 Firestore 或其他地方检索到的数据、我的 index.js 中的字符串常量和运行时环境变量，不会被记录或记录在全部。 最重要的是，不要暴露给触发 function; 的客户端。

如果运行时是安全的，并且不会将检索到的 Firestore 数据暴露给客户端，那么 Secret Manager 的必要性和更高的价格就会消失。

Answer 1

您从文档中引用的内容基本上是说 env vars 缺乏安全性，因为您与它们一起部署的任何代码（包括第三方库和模块）都可以自由且轻松地读取它们。 因此，在环境变量中放置高度“危险”的值，例如凭据和 API 密钥会使它们很容易被泄露（有意或无意）。 这就是这里的警告，仅此而已。

最重要的是，环境变量有时存储在源代码中，这通常是更糟糕的情况。 因此，您现在有两个理由不将环境变量用于必须保密的数据。

Secret Manager 是推荐的解决方案，因为它以最小权限原则运行，让您能够准确地确定谁或什么可以看到这些值，仅此而已。 这是安全性的最佳选择——您应该只向拥有秘密的人提供访问权限。

如果您使用 Firestore 之类的数据库来保存您的秘密，那么您将在实现最小权限时遇到问题。 这主要是因为任何对您的项目具有读取权限的人都可以简单地打开控制台并开始查看数据库。 您无法控制对这些单个文档的权限。 Firestore 不是为此而设计的。 Secret Manager 正是针对这种情况而设计的。

如果您是唯一可以访问您的项目控制台的人，那么您不会遇到这样的安全问题（目前）。 如果您想以最好的方式进行安全保护，或者只是使用更简单的解决方案，这完全取决于您。 由你决定。 或者，如果您隐含地信任使用 function 部署的所有代码，则可以使用 env var。 而且，如果您是唯一可以访问源代码控制的人，您甚至可以将值放在那里。

您可以看到每个人都有不同的安全情况，需要不同的解决方案。 选择一个满足您的特定需求的。 但是没有解决方案是真正“完全安全”的，因为某人或某事必须有权访问您的秘密，并且某人或某事可能会以某种方式受到损害。