運用 InSpec 自動化 Azure 基礎設施的 DevSecOps 合規

在現代雲端原生架構中，傳統的瀑布式安全審核模式已無法跟上敏捷開發與持續交付（CI/CD）的步伐。DevSecOps 應運而生，它不僅是一種方法論，更是一種文化轉變，強調開發、安全與維運團隊的共同責任。此模式的核心在於「安全左移」（Shift Left），將安全考量從部署後的被動檢測，提前至開發初期。本文將闡述如何透過「基礎設施即代碼」（IaC）的實踐，結合 Chef InSpec 這類自動化合規工具，將抽象的安全政策轉化為可執行、可驗證的程式碼。這種方法不僅提升了部署速度與可靠性，更重要的是，它讓雲端基礎設施的安全性與合規性變得透明、可追溯且能持續監控。

DevSecOps 實踐：整合安全於 DevOps 流程，以 InSpec 強化 Azure 基礎設施合規性

深入解析 DevSecOps 的核心理念與實踐，理解如何將安全左移至 DevOps 的早期階段。重點學習 Chef InSpec 工具，掌握其安裝、配置與應用，特別是如何針對 Azure 基礎設施編寫和執行合規性測試，確保雲端環境的安全性與標準化

本節將聚焦於 DevSecOps 的實踐。DevSecOps 的核心思想是將安全融入 DevOps 的每一個環節，從需求分析、開發、測試到部署和運維，都貫徹安全意識和實踐。我們將深入探討 DevSecOps 的重要性，並重點介紹 Chef InSpec，一個強大的開源框架，用於定義和執行基礎設施的合規性測試。我們將詳細講解 InSpec 的安裝、配置，以及如何編寫 InSpec 測試腳本來驗證 Azure 基礎設施的配置是否符合預期的安全標準和行業規範。最終目標是建立一個自動化的、可重複的合規性驗證流程，以確保雲端環境的安全性。

DevSecOps：將安全左移的理念

DevSecOps 的目標是打破開發 (Dev)、安全 (Sec) 和運維 (Ops) 之間的壁壘，讓安全成為整個軟體交付生命週期中不可或缺的一部分。

DevSecOps 的核心原則:
- 安全左移 (Shift Left Security): 在開發週期的早期階段就開始考慮和實施安全措施，而不是等到最後才進行安全審核。
- 自動化安全: 將安全檢查、掃描和測試自動化，使其成為 CI/CD 流程的一部分。
- 協作與共享責任: 開發、安全和運維團隊共同承擔安全責任，通過開放溝通和協作來解決安全問題。
- 持續安全監控: 在應用程式部署後，持續監控其安全狀態，並及時響應安全事件。
- 基礎設施即代碼 (Infrastructure as Code, IaC): 通過代碼來管理和配置基礎設施，並對這些代碼進行安全審查和測試。
DevSecOps 的實踐:
- 安全編碼培訓: 為開發者提供安全編碼的培訓。
- 靜態應用程式安全測試 (SAST): 在開發階段使用工具（如 SonarQube）掃描程式碼中的安全漏洞。
- 動態應用程式安全測試 (DAST): 在運行時測試應用程式的安全漏洞（如 ZAP）。
- 軟體組成分析 (SCA): 檢查應用程式依賴的第三方庫是否存在已知的安全漏洞。
- 基礎設施合規性測試: 使用工具（如 InSpec）驗證基礎設施的配置是否符合安全標準。
- 秘密管理: 使用專門的工具（如 Azure Key Vault, HashiCorp Vault）安全地管理敏感信息（API 密鑰、密碼、證書）。

Chef InSpec：基礎設施合規性自動化

Chef InSpec 是一個開源的框架，用於定義和執行基礎設施的合規性測試，確保伺服器、應用程式和雲端資源的配置符合預期的安全策略。

InSpec 的核心概念:
- 聲明式測試: 使用一種易於閱讀的 DSL (Domain Specific Language) 來描述期望的狀態。
- 資源 (Resources): InSpec 提供了一系列預定義的資源，用於描述和測試不同的系統組件，例如：
  - file: 測試文件是否存在、權限、內容。
  - port: 測試網絡端口是否開放。
  - service: 測試服務是否運行。
  - package: 測試軟件包是否安裝。
  - aws_s3_bucket, azure_resource_group, azure_virtual_machine: 用於測試雲端資源的配置。
- 控制 (Controls): 將相關的測試組織成一個個的控制，每個控制都代表一個合規性要求。
- 配置文件 (Profile): 將多個控制組織成一個配置文件，形成一個完整的合規性測試套件。
InSpec 安裝:
- Ruby 環境: InSpec 是基於 Ruby 的，需要先安裝 Ruby 和 RubyGems。
- Gem 安裝:
```
gem install inspec
```
- 驗證安裝:
```
inspec version
```
配置 Azure for InSpec:
- Azure CLI: 確保您的系統已安裝 Azure CLI，並已登錄到 Azure 帳戶。
- Azure 服務主體 (Service Principal): 為了讓 InSpec 能夠以程式化的方式訪問 Azure 資源，通常需要創建一個 Azure 服務主體，並為其分配必要的權限（例如，讀取資源組、虛擬機、網絡配置的權限）。
- 環境變數: 將服務主體的憑證信息設置為環境變數，以便 InSpec 可以讀取。
```
export AZURE_TENANT_ID="your-tenant-id"
export AZURE_CLIENT_ID="your-client-id"
export AZURE_CLIENT_SECRET="your-client-secret"
export AZURE_SUBSCRIPTION_ID="your-subscription-id"
```

編寫 InSpec 測試:

創建配置文件:
```
inspec init my_azure_profile
cd my_azure_profile
```
這將創建一個包含 inspec.yml 和 controls 目錄的基本配置文件。
編寫控制文件: 在 controls 目錄下創建 .rb 文件，例如 azure_vm_compliance.rb。

範例：測試 Azure 虛擬機的 SSH 端口:

# controls/azure_vm_compliance.rb
control 'vm-ssh-port' do
  impact 1.0
  title 'Ensure SSH port is not publicly exposed'
  desc 'The SSH port (22) should not be accessible from the internet.'

  # 使用 Azure 資源的 InSpec 資源
  # 這裡假設我們已經配置了 Azure CLI 或服務主體
  # 並且可以在 Azure 中找到 VM 的信息
  # 實際應用中，可能需要先獲取 VM 的公共 IP 或網絡安全組 (NSG) 信息

  # 簡化示例：假設我們知道 VM 的公共 IP 地址
  # 實際測試會更複雜，需要與 Azure API 交互
  # 這裡僅為說明概念

  # 假設我們有一個 Azure VM 的公共 IP 地址
  # 實際情況下，您需要通過 inspec-azure 插件來獲取這些信息
  # 例如：
  # azure_vm('my-vm-name', resource_group: 'my-resource-group').public_ip_address

  # 為了演示，我們直接測試本地端口，這不是對 Azure VM 的直接測試
  # 真正的 Azure VM 測試需要使用 inspec-azure 插件
  # 這裡僅作為概念演示，實際測試請參考 InSpec Azure 插件文檔

  # 示例：檢查本地端口 22 是否監聽（這不是對 Azure VM 的測試）
  # describe port(22) do
  #   it { should_not be_listening } # 理想情況下，公共 IP 上的 22 端口不應直接暴露
  # end

  # 實際 Azure 測試應類似於：
  # describe azure_network_security_group('my-nsg-name', resource_group: 'my-rg') do
  #   its('inbound_rules') { should_not include 'allow ssh from any' }
  # end

  # 為了演示，我們直接模擬一個檢查
  # 實際應用中，請使用 inspec-azure 插件提供的資源
  describe 'Azure VM Compliance Check' do
    it 'should have SSH port secured' do
      # 這裡應調用 Azure InSpec 資源來檢查 NSG 或 VM 的網絡配置
      # 例如：
      # expect(azure_network_security_group('my-nsg').rules).to_not include_rule_for_port(22).from_any_source
      # 為了演示，我們直接斷言一個成功的狀態
      expect(true).to be true
    end
  end
end

注意: 上述 Azure VM 測試示例是概念性的。實際測試需要使用 inspec-azure 插件，它提供了與 Azure API 交互的資源，用於檢查虛擬機、網絡安全組 (NSG)、存儲帳戶等資源的配置。

執行 InSpec:
- 本地執行:
```
inspec exec my_azure_profile --target azure://<tenant-id>/<subscription-id>/<resource-group>
```
  或者，如果配置了環境變數，可以直接執行：
```
inspec exec my_azure_profile --target azure://
```
- 使用 Profile 文件:
```
inspec exec my_azure_profile
```
  如果配置文件中定義了目標，則無需額外指定 --target。

保護敏感數據

在 DevSecOps 流程中，保護敏感數據（如密碼、 API 密鑰、證書）至關重要。

避免硬編碼: 絕對不要將敏感信息直接寫入程式碼、配置文件或 CI/CD 腳本中。
使用秘密管理服務:
- Azure Key Vault: Azure 提供的雲端服務，用於安全地存儲和管理密鑰、證書和秘密。
- HashiCorp Vault: 一個流行的開源工具，用於管理敏感數據。
- CI/CD 工具的秘密管理: 大多數 CI/CD 工具（如 Azure Pipelines, GitHub Actions）都提供了內建的秘密變數管理功能，可以安全地存儲敏感信息，並在管道執行時注入為環境變數。
訪問控制: 為訪問敏感數據的服務（如 CI/CD 代理、應用程式）配置最小權限原則。
定期輪換: 定期輪換密鑰和密碼，以降低安全風險。

DevSecOps 與 InSpec 流程圖示

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

start

partition "DevSecOps 與 InSpec 合規性測試" {
  partition "DevSecOps 理念" {
    :1. 安全左移;
    :2. 自動化安全測試;
    :3. 協作與共享責任;
    :4. 持續安全監控;
  }

  partition "基礎設施合規性測試 (InSpec)" {
    partition "準備階段" {
      :5. 安裝 InSpec;
      :6. 配置 Azure 服務主體 (Service Principal);
      :7. 設置 Azure 認證環境變數;
      :8. 創建 InSpec Profile (`inspec init`);
    }
    partition "編寫測試腳本" {
      :9. 編寫 InSpec Control 腳本 (.rb);
      :10. 使用 InSpec 資源描述期望狀態;
      :   - `file`, `port`, `service` (通用);
      :   - `azure_resource_group`, `azure_virtual_machine`, `azure_network_security_group` (Azure 特定);
      :11. 定義合規性要求 (Impact, Title, Desc);
    }
    partition "執行與驗證" {
      :12. 執行 InSpec 測試 (`inspec exec`);
      :13. InSpec 連接 Azure API 驗證配置;
      :14. 報告測試結果 (Pass/Fail);
      :15. (進階) CI/CD 整合 InSpec 進行自動化驗證;
    }
  }

  partition "敏感數據保護" {
    :16. 避免硬編碼敏感信息;
    :17. 使用 Azure Key Vault 或 CI/CD 秘密管理;
    :18. 配置最小權限訪問;
  }
}

stop

@enduml

看圖說話：

此圖示全面展示了 DevSecOps 的理念以及如何利用 Chef InSpec 進行 Azure 基礎設施的合規性測試。開頭的「DevSecOps 理念」部分，簡潔地闡述了其核心原則，強調了安全左移和自動化。圖示的主體「基礎設施合規性測試 (InSpec)」部分，將流程細分為準備階段、編寫測試腳本和執行與驗證三個環節。在準備階段，列出了安裝 InSpec 和配置 Azure 認證的關鍵步驟。編寫測試腳本部分，重點說明瞭如何利用 InSpec 資源來描述期望狀態，並強調了 Azure 特定資源的使用。執行與驗證階段，則展示了 InSpec 命令的執行過程和結果報告，並提及了 CI/CD 的整合。最後，「敏感數據保護」部分，提供了關於如何安全管理敏感信息的實用建議。這張圖有效地呈現了 DevSecOps 的實踐方法，特別是如何通過 InSpec 確保雲端基礎設施的合規性。

結論

縱觀現代雲端維運的複雜挑戰，將安全合規性從被動審計轉化為主動內建，已是不可逆的趨勢。InSpec 的實踐，其核心價值在於將抽象的安全政策轉譯為精確、可自動驗證的程式碼，形成一種數位治理資產。然而，真正的瓶頸並非工具的學習曲線，而是建立跨職能團隊共同維護「合規即代碼」的協作文化與流程。將其無縫整合至 CI/CD，使其成為如單元測試般自然的前置關卡，才是確保理念落地的關鍵。

展望未來，此「即代碼」治理模式將從基礎設施擴展至應用與數據層面，建構更全面的自動化信任鏈。對於追求高效與穩健的管理者，應將此視為一項策略性投資，優先建構此能力，才能將風險管理轉化為穩固的組織競爭力。

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。