本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 實作集中式自訂 Checkov 掃描，以在部署 AWS 基礎設施之前強制執行政策 *Benjamin Morris，Amazon Web Services* ## 總結 此模式提供 GitHub Actions 架構，可在一個儲存庫中撰寫自訂 Checkov 政策，以便在 GitHub 組織中重複使用。透過遵循此模式，資訊安全團隊可以根據公司要求撰寫、新增和維護自訂政策。自訂政策可以自動提取到 GitHub 組織中的所有管道。此方法可用於在資源部署之前強制執行公司資源標準。 ## 先決條件和限制 **先決條件 ** + 作用中 AWS 帳戶 + 使用 GitHub 動作的 GitHub 組織 + AWS 使用 HashiCorp Terraform 或 部署的 基礎設施 AWS CloudFormation **限制 ** + 此模式適用於 GitHub 動作。不過，它可以適應類似的持續整合和持續交付 (CI/CD) 架構，例如 GitLab。不需要特定版本的 GitHub。 + 有些 AWS 服務 完全無法使用 AWS 區域。如需區域可用性，請參閱 AWS 文件中的[服務端點和配額](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)，然後選擇服務的連結。 ## Architecture 此模式旨在部署為 GitHub 儲存庫，其中包含 GitHub 可重複使用的工作流程和自訂 Checkov 政策。可重複使用的工作流程可以將 Terraform 和 CloudFormation 基礎設施掃描為程式碼 (IaC) 儲存庫。 下圖以個別圖示顯示**可重複使用的 GitHub 工作流程儲存庫**和**自訂 Checkov 政策儲存庫**。不過，您可以將這些儲存庫實作為個別儲存庫或單一儲存庫。範例程式碼使用單一儲存庫，其中包含工作流程 (`.github/workflows`) 的檔案，以及相同儲存庫中自訂政策 `.checkov.yml` (`custom_policies` 資料夾和組態檔案） 的檔案。 ![\[GitHub 動作使用可重複使用的 GitHub 工作流程和自訂 Checkov 政策來評估 IaC。\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/patterns/images/pattern-img/6c0c941f-14f9-4569-92da-9f81ab3e525c/images/a1539ce5-0ee6-4af1-bd01-cafad0f71708.png) 該圖顯示以下工作流程： 1. 使用者在 GitHub 儲存庫中建立提取請求。 1. 管道工作流程從 GitHub 動作開始，包括對 Checkov 可重複使用工作流程的參考。 1. 管道工作流程會從外部儲存庫下載參考的 Checkov 可重複使用工作流程，並使用 GitHub 動作執行該 Checkov 工作流程。 1. Checkov 可重複使用工作流程會從外部儲存庫下載自訂政策。 1. Checkov 可重複使用工作流程會根據內建和自訂 Checkov 政策來評估 GitHub 儲存庫中的 IaC。Checkov 可重複使用工作流程會根據是否發現安全問題而通過或失敗。 **自動化和擴展** 此模式允許對 Checkov 組態進行集中管理，以便可以在一個位置套用政策更新。不過，此模式確實要求每個儲存庫使用包含中央可重複使用工作流程參考的工作流程。您可以手動新增此參考，或使用指令碼將檔案推送到每個儲存庫的 `.github/workflows` 資料夾。 ## 工具 **AWS 服務** + [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 可協助您設定 AWS 資源、快速且一致地佈建資源，以及在整個 AWS 帳戶 和 區域的生命週期中管理資源。Checkov 可以掃描 CloudFormation。 **其他工具** + [Checkov](https://www.checkov.io/) 是一種靜態程式碼分析工具，可檢查 IaC 的安全性和合規性設定錯誤。 + [GitHub Actions](https://github.com/features/actions) 已整合至 GitHub 平台，協助您在 GitHub 儲存庫中建立、共用和執行工作流程。您可以使用 GitHub 動作來自動化任務，例如建置、測試和部署程式碼。 + [Terraform](https://www.terraform.io/) 是 HashiCorp 的 IaC 工具，可協助您建立和管理雲端和內部部署資源。Checkov 可以掃描 Terraform。 **程式碼儲存庫** 此模式的程式碼可在 GitHub [centralized-custom-checkov-sast](https://github.com/aws-samples/centralized-custom-checkov-sast) 儲存庫中使用。 ## 最佳實務 + 若要維持一致的安全狀態，請讓公司的安全政策與 Checkov 政策保持一致。 + 在實作 Checkov 自訂政策的早期階段，您可以使用 Checkov 掃描中的軟失敗選項，以允許合併具有安全問題的 IaC。隨著程序的成熟，從軟失敗選項切換到硬失敗選項。 ## 史詩 ### 建立自訂政策的中央 Checkov 儲存庫 | 任務 | Description | 所需的技能 | | --- | --- | --- | | 建立中央 Checkov 儲存庫。 | 建立儲存庫以存放將在組織內使用的自訂 Checkov 政策。為了快速入門，您可以將此模式的 GitHub [centralized-custom-checkov-sast ](https://github.com/aws-samples/centralized-custom-checkov-sast)儲存庫的內容複製到中央 Checkov 儲存庫。 | DevOps 工程師 | | 建立可重複使用工作流程的儲存庫。 | 如果可重複使用工作流程的儲存庫已存在，或者您計劃在與自訂 Checkov 政策相同的儲存庫中包含可重複使用的工作流程檔案，您可以略過此步驟。建立 GitHub 儲存庫以保留可重複使用的工作流程。其他儲存庫的管道將參考此儲存庫。 | DevOps 工程師 | ### 建立可重複使用和範例 Checkov 工作流程 | 任務 | Description | 所需的技能 | | --- | --- | --- | | 新增可重複使用的 Checkov 工作流程。 | 在可重複使用的工作流程儲存庫中建立可重複使用的 Checkov GitHub 動作工作流程 (YAML 檔案）。您可以從此模式提供的工作流程檔案中調整此可重複使用的工作流程。您可能想要進行的變更範例是將可重複使用的工作流程變更為使用軟失敗選項。`soft-fail` 將 設定為 `true` 可讓任務順利完成，即使 Checkov 掃描失敗也一樣。如需說明，請參閱 Checkov 文件中的[硬性與軟性故障](https://www.checkov.io/2.Basics/Hard%20and%20soft%20fail.html)。 | DevOps 工程師 | | 新增工作流程範例。 | 新增參考工作流程的範例 Checkov `reusable`工作流程。這將提供範本，說明如何重複使用`reusable`工作流程。在範例儲存庫中， `checkov-source.yaml` 是可重複使用的工作流程，而 `checkov-scan.yaml`是使用 的範例`checkov-source`。如需撰寫範例 Checkov 工作流程的詳細資訊，請參閱[其他資訊](#centralized-custom-checkov-scanning-additional)。 | DevOps 工程師 | ### 將公司政策與 Checkov 自訂政策建立關聯 | 任務 | Description | 所需的技能 | | --- | --- | --- | | 決定可使用 Checkov 強制執行的政策。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/patterns/centralized-custom-checkov-scanning.html)如需建立 Checkov 自訂政策的詳細資訊，請參閱 Checkov 文件中的[自訂政策概觀](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html)。 | 安全與合規 | | 新增 Checkov 自訂政策。 | 將已識別的公司政策轉換為中央儲存庫中的自訂 Checkov 政策。您可以在 Python 或 YAML 中撰寫簡單的 Checkov 政策。 | 安全 | ### 實作集中式 Checkov 自訂政策 | 任務 | Description | 所需的技能 | | --- | --- | --- | | 將 Checkov 可重複使用工作流程新增至所有儲存庫。 | 此時，您應該有一個參考可重複使用工作流程的範例 Checkov 工作流程。將參考可重複使用工作流程的範例 Checkov 工作流程複製到每個需要該工作流程的儲存庫。 | DevOps 工程師 | | 建立機制以確保 Checkov 在合併之前執行。 | 為了確保針對每個提取請求執行 Checkov 工作流程，請建立需要成功 Checkov 工作流程才能合併提取請求[的狀態檢查](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks)。GitHub 可讓您要求特定工作流程執行，才能合併提取請求。 | DevOps 工程師 | | 建立整個組織的 PAT，並將其做為秘密共用。 | 如果您的 GitHub 組織可公開看見，您可以略過此步驟。此模式需要 Checkov 工作流程能夠從 GitHub 組織中的自訂政策儲存庫下載自訂政策。您必須提供許可，讓 Checkov 工作流程可以存取這些儲存庫。若要這樣做，[請建立具有讀取組織儲存庫許可的個人存取字符](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token) (PAT)。將此 PAT 與儲存庫共用，可以是整個組織的秘密 （如果在付費計劃中） 或每個儲存庫中的秘密 （免費版本）。在範例程式碼中，秘密的預設名稱為 `ORG_PAT`。 | DevOps 工程師 | | （選用） 防止 Checkov 工作流程檔案遭到修改。 | 若要保護 Checkov 工作流程檔案免於不必要的變更，您可以使用 `CODEOWNERS` 檔案。`CODEOWNERS` 檔案通常部署在 目錄的根目錄中。例如，若要在修改`checkov-scan.yaml`檔案時要求 GitHub 組織的 `secEng` 群組核准，請將下列項目附加至儲存庫的 `CODEOWNERS` 檔案：
[Checkov]
.github/workflows/checkov-scan.yaml @myOrg/secEng
`CODEOWNERS` 檔案專屬於其所在的儲存庫。若要保護儲存庫使用的 Checkov 工作流程，您必須在每個儲存庫中新增 （或更新） `CODEOWNERS` 檔案。如需保護 Checkov 工作流程檔案的詳細資訊，請參閱[其他資訊](#centralized-custom-checkov-scanning-additional)。如需`CODEOWNERS`檔案的詳細資訊，請參閱 CI/CD 提供者的官方文件 （例如 [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners))。 | DevOps 工程師 | ## 相關資源 + [Checkov 自訂政策概觀](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html) + [CloudFormation 組態掃描](https://www.checkov.io/7.Scan%20Examples/Cloudformation.html) + [GitHub 動作可重複使用的工作流程](https://docs.github.com/en/actions/using-workflows/reusing-workflows) ## 其他資訊 **撰寫 Checkov 工作流程檔案** 寫入 時`checkov-scan.yaml`，請考慮何時要執行。最上層`on`金鑰決定工作流程何時執行。在範例儲存庫中，當有以`main`分支為目標的提取請求時 （以及只要修改提取請求的來源分支時），工作流程就會執行。由於 `workflow_dispatch`金鑰，工作流程也可以視需要執行。 您可以根據您希望工作流程執行的頻率來變更工作流程觸發條件。例如，您可以將 `pull_request`取代為 `push` 並移除`branches`金鑰，將工作流程變更為每次將程式碼推送至任何分支時執行。 您可以修改在個別儲存庫中建立的範例工作流程檔案。例如，`production`如果儲存庫是圍繞分支建構的，您可以將目標`production`分支的名稱從 `main` 調整為 。 **保護 Checkov 工作流程檔案** Checkov 掃描提供有關潛在安全錯誤組態的有用資訊。不過，有些開發人員可能會認為這是生產力的障礙，並嘗試移除或停用掃描工作流程。 有幾種方法可以解決此問題，包括更清楚的安全掃描長期價值的訊息，以及更清楚如何部署安全基礎設施的文件。這些是 DevSecOps 協同合作的重要「軟」方法，可視為此問題根本原因的解決方案。不過，您也可以使用像是 `CODEOWNERS` 檔案之類的技術控制項做為護欄，協助開發人員保持在正確的路徑上。 **在沙盒中測試模式** 若要在沙盒環境中測試此模式，請遵循下列步驟： 1. 建立新的 GitHub 組織。建立具有組織中所有儲存庫唯讀存取權的字符。由於此字符適用於沙盒環境，而非付費環境，因此您將無法將此字符存放在整個組織的秘密中。 1. 建立儲存`checkov`庫以保留 Checkov 組態，以及建立儲存`github-workflows`庫以保留可重複使用的工作流程組態。使用範例儲存庫的內容填入儲存庫。 1. 建立應用程式儲存庫，並將`checkov-scan.yaml`工作流程複製並貼到其`.github/workflows`資料夾。將秘密新增至儲存庫，其中包含您為組織唯讀存取建立的 PAT。預設秘密為 `ORG_PAT`。 1. 建立提取請求，將一些 Terraform 或 CloudFormation 程式碼新增至應用程式儲存庫。Checkov 應掃描並傳回結果。