無論是微服務還是單體應用，往往都會用到很多配置資訊。在眾多的配置資訊中，有一類非常敏感，例如資料庫賬號密碼、API Key、Service Account等。由於其特殊性，這些配置資訊一旦洩露出去就很可能會使得應用遭到黑客攻擊，例如資料庫賬號密碼洩露可能導致“拖庫”，甚至資料丟失。
在實際開發過程中，有幾種常見的敏感配置資訊管理方式，其優缺點各不相同，讓我們依次來看看。
三種常見方式
方式一：儲存於獨立的原始碼倉庫
將敏感配置資訊硬編碼到原始碼中是一種古老的做法，由於其安全性難以得到保證，並且管理維護難度大，因此早已被開發團隊摒棄。
取而代之的是將敏感配置資訊儲存在配置檔案中，並且將其單獨放置於另外一個原始碼倉庫，在CI構建或者部署過程中，由CI從對應的原始碼倉庫中獲取配置資訊，然後將其打入應用包。
這種方式最大的好處在於團隊可以方便的對原始碼倉庫新增訪問控制，但是缺點也是比較明顯的：敏感配置資訊並沒有被加密儲存，而且會被CI伺服器快取下來。
方式二：通過系統環境變數動態設定
這是一種另闢蹊徑的做法，即把敏感配置資訊設定到系統環境變數裡，而不是儲存在配置檔案中。 這背後的邏輯是，既然敏感配置資訊明文儲存不夠安全，就算加密儲存也存在被破解的可能，那麼就乾脆不儲存了。
此種方式看上去非常巧妙但也隱含著一些問題。系統環境變數不可能憑空出現，必然需要有一個“主體”去設定它，而這個所謂的“主體”不外乎是人、CI或者指令碼。
通過人來設定環境變數十分低效且易出錯，而如果通過CI或者指令碼來自動進行設定，看似提高了效率但敏感配置資訊也就快取在了CI中，或者作為指令碼檔案的一部分儲存在了原始碼倉庫中。方式一中遇到的問題再次出現。
方式三：在執行時從配置中心動態獲取
隨著微服務、容器化變得越來越流行，配置中心幾乎已經成為了這一領域裡的標準配置。
這種方式下，所有的配置資訊（無論其敏感與否）都統一儲存在配置中心，應用在啟動或者執行過程中通過HTTPS從配置中心動態獲取配置。由於所有的配置資訊都集中在一起，並且由應用以自助的方式獲取，因此非常便於維護管理。
最為關鍵的是，採用這種方式既可以方便的實現敏感配置資訊加密儲存，又具備完善的許可權控制能力，而且還能提供詳細的日誌記錄。
目前有不少工具或者框架可供開發團隊選擇，以搭建出這樣的配置中心，常見的例如Hashicorp Vault ，Spring Cloud Config。如果是Cloud Native應用，還可以使用雲平臺提供的安全配置管理服務，例如微軟Azure的Key Vault。
然而配置中心的方式並非完美，依然有值得注意的地方。由於大量應用依賴於這個配置中心，因此單點失敗的概率相比於其他幾種方式會有所提高。此外，敏感配置資訊會在網路上傳輸，因此傳輸過程的安全性也需要考慮在內，建議對其啟用HTTPS。再者，配置中心也是眾多微服務中的一個，考慮到它的特殊性，團隊十分有必要對其新增適當的網路訪問控制，例如僅允許從企業內部進行訪問。
6個原則
各個團隊所面臨的實際情況很可能千差萬別，並且本文所述的幾種方式可能並非涵蓋了所有的敏感配置資訊管理方式。無論你的團隊採用的是哪種方式，在使用過程中都可以參考下面這些原則，以保證敏感配置資訊的安全性：
- 適度隔離：將敏感配置資訊同原始碼、普通配置資訊隔離儲存。
- 訪問控制：通過白名單等方式，限制敏感配置資訊的訪問許可權。
- 加密儲存：將敏感配置資訊加密後儲存，僅在使用前臨時解密，以進一步防止資訊洩露。
- 安全傳輸：企業內網環境並非100%可信，通過HTTPS等加密手段以保證敏感配置資訊的傳輸安全。
- 日誌記錄：儘量詳細記錄下針對配置資訊的操作，以便於事後追查或者合規審查。
- 差別配置：不同的環境（例如生產環境，UAT環境，Dev環境等）使用不同的Credential，以避免“把雞蛋放到一個籃子裡”。
總結
應用往往需要用到配置資訊，其中一些由於其特殊性會相比於其他配置資訊更加敏感，它們需要被很好的保護起來以避免應用遭受黑客攻擊。
不同的敏感配置資訊管理方式有著各自的特點。將敏感配置資訊單獨儲存於原始碼倉庫中的方式常見於單體應用架構，與此同時配置中心在微服務架構下更為常見，而使用環境變數這種方式的團隊也不在少數。
沒有絕對的好，也沒有絕對的壞。團隊採用哪種方式不是最重要的，關鍵在於是否遵循了一些基本的原則以保證敏感配置資訊的安全性。