我剛剛從第一代 Firebase 功能遷移到第二代。在本檔案中，寫到：GCP 不保證以 env 變數形式存盤的資料的純粹安全性。文章還推薦使用Secret Manager，它比 Firestore 的讀取操作要貴得多。這也意味著 Google 不保證 Firebase 函式運行時環境變數的安全性。我在第二代 Firebase 函式中使用 Node.js 16 運行時。
第二代 Firebase 函式的 Node.js 16 運行時環境是否足夠安全，可以在運行時使用敏感資料？我計劃在第二代 Firebase 函式的 Node.js 16 運行時中從 Firestore 讀取最敏感的資料，并在不將其記錄在我的代碼中的情況下使用它。但是，如果像 env 變數這樣的安全資料可以記錄在某種運行時（上述檔案中未指定），那么找出并處理此類安全例外會讓我感到沮喪。所以我想確保在第二代 Firebase Functions 的 Node.js 16 運行時中從 Firestore 檢索到的資料是完全安全的。不幸的是，我找不到任何適當的檔案來指定 Node.js 16 運行時的這種安全保證。
正如評論中提到的@Doug，completely safe在背景關系中太模棱兩可了。因此，這是問題中安全性的詳細資訊：
環境變數可用于功能配置，但不建議將其用作存盤資料庫憑據或 API 密鑰等機密的方式。這些更敏感的值應該存盤在您的源代碼和外部環境變數之外。某些執行環境或某些框架的使用可能會導致環境變數的內容被發送到日志中，不建議將敏感憑據存盤在 YAML 檔案、部署腳本或源代碼控制下。對于存盤機密，我們建議您查看機密管理的最佳實踐。請注意，Cloud KMS 沒有特定于 Cloud Functions 的集成。
背景關系中的安全性如下：考慮到官方檔案的上述評論，我想確保我從 Firestore 或其他地方檢索到的資料、我的 index.js 中的字串常量和運行時環境變數，不會被記錄或記錄在全部。最重要的是，不要暴露給觸發該功能的客戶端；。
如果運行時是安全的，并且不會將檢索到的 Firestore 資料暴露給客戶端，那么 Secret Manager 的必要性和更高的價格就會消失。
uj5u.com熱心網友回復：
您從檔案中參考的內容基本上是說 env vars 缺乏安全性，因為您與它們一起部署的任何代碼（包括第三方庫和模塊）都可以自由且輕松地讀取它們。出于這個原因，在環境變數中放置高度“危險”的值，例如憑據和 API 密鑰，會使它們很容易被泄露（有意或無意）。這就是這里的警告，僅此而已。
最重要的是，環境變數有時存盤在源代碼中，這通常是更糟糕的情況。因此，您現在有兩個理由不將環境變數用于必須保密的資料。
Secret Manager 是推薦的解決方案，因為它以最小權限原則運行，讓您能夠準確地確定誰或什么可以看到這些值，僅此而已。這是安全性的最佳選擇——您應該只向擁有秘密的人提供訪問權限。
如果您使用 Firestore 之類的資料庫來保存您的秘密，那么您將在實作最小權限時遇到問題。這主要是因為任何對您的專案具有讀取權限的人都可以簡單地打開控制臺并開始查看資料庫。您無法控制對這些單個檔案的權限。Firestore 不是為此而設計的。Secret Manager 正是針對這種情況而設計的。
如果您是唯一可以訪問您的專案控制臺的人，那么您不會遇到這樣的安全問題（目前）。如果您想以最好的方式進行安全保護，或者只是使用更簡單的解決方案，這完全取決于您。由你決定。或者，如果您隱含地信任使用函式部署的所有代碼，則可以使用 env vars。而且，如果您是唯一可以訪問源代碼控制的人，您甚至可以將值放在那里。
您可以看到每個人都有不同的安全情況，需要不同的解決方案。選擇一個滿足您的特定需求的。但是沒有解決方案是真正“完全安全”的，因為某人或某事必須有權訪問您的秘密，并且某人或某事可能會以某種方式受到損害。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/507514.html