當工作負載需要在沒有終端使用者參與的情況下存取資源或進行操作時，就會需要使用到 Google Cloud 上的服務賬戶。有多種使用服務賬戶進行認證的方法，包括將服務賬戶作為 Google Compute Engine 執行實體的一部分、或者冒充服務賬戶，或者使用帶有密鑰文件的服務賬戶，使用服務帳戶進行認證是一個應該需要慎重考慮的選項。
一個共同的目標是在 Google Cloud 上實現無密鑰的服務賬戶架構，但這在整個組織中可能是較難實現，團隊可能選擇生成服務賬戶密鑰的原因有很多，從開發者驗證到第三方軟體的集成都有這需求。
在這篇文章中，我們將會探討在無法避免使用服務賬戶密鑰時，你可以通過哪些方式來降低風險。我們將專注在提供了解 Google Cloud 內服務賬戶使用情況的見解，這可以使得我們在輪換服務賬戶密鑰時減少出現非預期故障的風險。讓我們開始吧!
來自互聯網安全中心(CIS) 基準的指引
互聯網安全中心 (CIS) 的基準提供了一套建議的資安加強指南。關於 Google Cloud Platform，CIS 最近發布了 CIS Google Cloud Platform Foundation Benchmark version 1.2.0，提供了一系列的操作、描述、理由、影響、審查步驟和補救措施，以改善你在 GCP 基礎服務上的整體安全狀況。
讓我們看看 CIS Google Cloud Platform Foundation Benchmark version 1.2.0 中，在章節 1.7 中的一個直接例子。該基準是這樣寫的﹕「確保用戶管理的/服務賬戶的外部密鑰每 90 天或更短時間內輪換一次（自動）」
本節會附有理由、影響、CLI 指令等，對於目的是什麼、為什麼要這麼做以及如何達到這一基準提供了寶貴的見解。CIS 指出，輪換服務賬戶密鑰可以「減少 」與潛在受攻擊賬戶相關的存取的機會。補救措施是輪換你的服務賬戶密鑰﹕
- 審查和識別 90 天以上仍未輪換的密鑰
- 刪除在範圍內的密鑰
- 建立一個新的密鑰（如果需要的話）。
在參考上述 3 個步驟時，這個過程似乎很簡單，然而有一些細微的範例你是需要注意的。
當你刪除一個服務帳戶密鑰時，將會非常有效地移除掉對相關私人密鑰的所有當前和未來的存取，但這可能會導致意想不到的後果，例如失去對依賴基礎密鑰文件的應用程式、管道或第三方集成的存取。那麼，我們怎樣才能防止這種情況呢？
調查一個服務賬戶的存取權限和使用情況
一種方法是對 GCP 服務賬戶和服務賬戶密鑰的存取和使用進行調查。讓我們引入 3 個 GCP 服務﹕Policy Analyzer、Policy Intelligence 和 Cloud Logging。這些工具都可以幫助我們調查清楚刪除指定的服務賬戶密鑰的影響。
對於我們的調查，我們應該考慮以下幾個問題﹕
- 這個服務賬戶能做什麼？ (Policy Analyzer)
GCP 中的 IAM 角色定義了一個服務賬戶可以做什麼。角色從組織節點到文件夾再到專案都是分層繼承的。 IAM 角色也可以在 GCP 項目中的許多資源上定義，包括 GCS 值區、KMS 密鑰環、服務賬戶等等。
編寫一個腳本，來確定一個服務賬戶所擁有的所有 IAM 綁定，可能是相當乏味的。虛擬碼大概是像這樣的﹕
for ALL folders in the organization:
for ALL projects in each folder:
for ALL resources in each project:
get and review EACH resource's iam policy
get and review the project iam policy
get and review the folder iam policy
get and review the organization iam policy
如果你的組織恰好有不止幾個資源，這可能會變得太令人厭倦，無法進行有意義的處理及分析。那麼我們能做什麼呢？這就是Policy Analyzer 發揮作用的時候，Policy Analyzer 可以啟用審計相關任務的存取可見性，並且允許在整個組織內進行查詢。下面的截圖顯示了 Policy Analyzer Query 的關鍵組成部分，查詢範圍、主體（或服務賬戶）、以及一組高級選項。查詢的結果將會是服務賬戶在整個組織內被授予的所有資源的角色的一個集合。
為了方便及重複使用，這裡有一個範例的連結﹕請參考此連結
這個查詢指令可以大大地幫助確定這個服務賬戶可能擁有的存取範圍。該服務賬戶可能在一個單一的 GCP 專案中擁有存取權，在組織層面上擁有存取權，或者在任意的資源中擁有存取權。使用 Policy Analyzer 使得我們能夠充分了解我們的服務賬戶有可能被使用的地方。
- 該服務賬戶最後一次使用是什麼時候？ (搭配 Policy Intelligence)
能夠了解我們的服務賬戶最後一次使用的時間也是有價值的。例如我們的服務賬戶在過去一年中沒有被使用，那麼很可能它是可以安全地被刪除。Policy Intelligence 服務能夠允許我們去查詢服務賬戶的活動。這個指令可以查詢到指定 GCP 專案的服務賬戶最後一次認證或服務賬戶密鑰最後一次認證的活動。下面是一個示範例子﹕
gcloud policy-intelligence query
-activity --activity-type=serviceAccountLastAuthentication
--project [YOUR_PROJECT_ID]
--query-filter='activities.full_resource_name="//iam.
googleapis.com/projects/[YOUR_PROJECT_ID]/serviceAccounts
/[SERVICE_ACCOUNT_EM
AIL]"'
能夠知道服務賬戶在特定的觀察期內進行了認證，也是這個服務賬戶是否被使用的一個指標。如果一個服務賬戶最近被使用過（我把「最近」的定義留給你和你的組織），你可能要在刪除服務賬戶密鑰之前更加謹慎小心。
此外，如果你碰巧有一個以上的服務賬戶密鑰，使用 Policy Intelligence 來識別一個密鑰的最後一次認證可以提供更多的顆粒度（這不是推薦的做法）。另一方面，如果我們沒有看到被查詢的服務賬戶有最近的活動，我們應該更加能夠確定，刪除服務賬戶不太可能有意外的後果。
Policy Intelligence 是以專案劃分範圍的，所以如果我們的服務賬戶有跨越多個專案的角色，我們將需要在每個專案中運行這個查詢。此外 Policy Intelligence 會回傳一個特定觀察時間內的結果，但是觀察期可能不包括最近的活動（比如說﹕幾分鐘前的活動），所以我們也可以參考 Cloud Logging…
- 這個服務賬戶最近做了什麼？ (Cloud Logging)
為了了解我們的服務賬戶最近所做的一切行為，我們將需要利用 Cloud Logging。為了查詢特定時間範圍內的活動列表。我們可以使用下面的日誌查詢指令﹕
protoPayload.authenticationInfo.
principalEmail="[SA_NAME]@[YOUR_PROJECT_ID].
iam.gserviceaccount.com"對於一個給定的服務賬戶密鑰，我們可以更進一步，運行以下日誌查詢﹕
protoPayload.authenticationInfo.serviceAccountKeyName="//
iam.googleapis.com/projects/[YOUR_PROJECT_ID]/serviceAccounts
/[YOUR_SA]@[YOUR_PROJECT_ID]
.iam.gserviceaccount.com/keys/[KEY_ID]"在進行這種基於 Cloud Logging 的調查時，有幾個需要注意的要點。首先，GCP 中並非所有的日誌類型都是默認啟用的（例如，數據存取日誌或 VPC 流量日誌）。如果我們需要看到這種日誌類型的顆粒度，我們需要確保在相應的資源上啟用日誌功能。其次，在多個專案間進行查詢可能會很繁瑣，因此我們不妨圍繞在關鍵時間點，例如輪換密鑰時候做出的基於風險的決定，或者通過使用日誌匯出，將我們的日誌導出到一個集中的位置，並在 BigQuery 或類似工具中進行整體分析。
歸納以上的結論
現在你應該對圍繞著服務賬戶的密鑰使用當中的一些風險以及減輕風險的策略有了很好的認識。首先，要儘量避免建立服務賬戶密鑰，例如使用 GCP 管理的一些選項，如工作負載身份、虛擬機服務賬戶或服務賬戶冒充等，都可以限制需要生成服務賬戶密鑰的範例數量。
第二，如果你確實有用戶管理的服務賬戶密鑰，要確保你會定期輪換這些密鑰。 90 天是一個合理的基準線，但自動輪換密鑰的頻率最好少於 90 天。
最後，如果你有一個專案的服務賬戶密鑰，但你不太確定它的預期用途（例如，有可能發生在一個由許多用戶共享的單一專案中），利用 GCP 的 3 個建議工具：日誌查詢、Policy Analyzer 和 Policy Intelligence，以減少刪除密鑰時，出現意外故障的機會。
雖然這些建議沒有提供一個完美的證明機制去識別服務賬戶的使用情況，但這些措施應該能夠在安全輪換服務帳戶密鑰這個過程中減少風險，並提高你對這能力的信心。
