Git 儲存函式庫安全防護實踐

– 12 分鐘閱讀

隨著開源協作的普及，Git 儲存函式庫安全的重要性日益凸顯。程式碼中不慎提交的敏感資訊，例如 API 金鑰、資料函式庫密碼等，可能成為攻擊者的目標。因此，開發者需要採取積極的措施來保護儲存函式庫安全。本文將介紹 Gitleaks 和 GitRob 兩款工具，它們可以幫助開發者自動化檢測和防範儲存函式庫中的安全風險，並進一步探討如何強化 Linux 主機安全，包含 EBS 磁碟區加密和 Ansible 自動化組態等實務做法，以建立更安全的開發環境。

保護你的 Git 儲存函式庫安全

在現代軟體開發中，Git 儲存函式庫的安全性至關重要。隨著開源軟體的盛行，開發者們往往同時管理著多個私有和公開的儲存函式庫。如何有效地分類別和管理這些儲存函式庫，避免潛在的安全風險，是每位開發者都需要關注的問題。

資訊洩漏的風險

公開儲存函式庫中不小心洩漏敏感資訊，可能會導致嚴重的後果。攻擊者可以利用這些資訊進行針對性的網路釣魚攻擊。因此，開發者必須小心處理公開儲存函式庫中的資訊，避免洩漏開發者的真實姓名、使用者名稱、公司、部門和電子郵件地址等敏感資訊。

GitHub 提供了一個頁面，介紹如何安全地在程式碼儲存函式庫中儲存和加密敏感資訊。開發者可以參考這個頁面來學習如何正確地管理敏感資訊。

自動化工具的安裝與組態

為了更好地保護 Git 儲存函式庫的安全，我們可以使用一些自動化工具來輔助檢查和防範潛在的安全風險。以下是兩款流行的工具：Gitleaks 和 GitRob。

Gitleaks 的安裝與使用

Gitleaks 是一款用於檢測 Git 儲存函式庫中硬編碼敏感資訊（如密碼、API 金鑰和令牌）的 SAST 工具。我們可以使用 Docker 來執行 Gitleaks，以避免安裝複雜性。

安裝 Gitleaks

首先，從 Docker Hub 下載 Gitleaks 的映像檔：

$ docker pull zricethezav/gitleaks

下載完成後，可以使用以下命令執行 Gitleaks：

$ docker run zricethezav/gitleaks --repourl=https://github.com/chrisbinnie/CloudNativeSecurity --redact

組態 Gitleaks

Gitleaks 提供了一個預設的組態檔案，其中包含了許多有用的規則。開發者可以根據需要對這些規則進行微調。例如，其中一條規則用於檢測 AWS 的秘密金鑰：

[[rules]]
description = "AWS Secret Key"
regex = '''(?i)aws(.{0,20})?(?-i)['\"][0–9a-zA-Z\/+]{40}['\"]'''
tags = ["key", "AWS"]

這條規則使用正規表示式來比對典型的 AWS 秘密金鑰格式。

使用 Gitleaks 掃描儲存函式庫

我們可以使用 Gitleaks 來掃描一個包含假的 AWS 憑證的檔案 secret_key.txt：

$ docker run zricethezav/gitleaks --repourl=https://github.com/chrisbinnie/CloudNativeSecurity -v

掃描結果顯示，在該儲存函式庫中發現了兩個洩漏。

程式碼解析

以下是上述命令的詳細解析：

  • docker run zricethezav/gitleaks：執行 Gitleaks 的 Docker 容器。
  • --repourl=https://github.com/chrisbinnie/CloudNativeSecurity：指定要掃描的 GitHub 儲存函式庫 URL。
  • -v：啟用詳細輸出模式，以便更清楚地瞭解掃描結果。

詳細輸出

透過啟用詳細輸出模式，我們可以獲得更詳細的掃描結果，如 Listing 10.1 所示。這有助於開發者更好地瞭解 Gitleaks 檢測到的問題。

使用Gitleaks保護Git儲存函式庫的安全

在DevSecOps的實踐中，確保Git儲存函式庫的安全至關重要。開發人員經常無意中將敏感資訊，如AWS存取金鑰，提交到程式碼函式庫中。Gitleaks是一種流行的開源工具，用於掃描Git儲存函式庫中的敏感資料洩露。本章將探討如何使用Gitleaks來增強Git儲存函式庫的安全性。

Gitleaks的基本使用

Gitleaks可以透過Docker容器輕鬆執行。只需執行以下命令，即可對指定的GitHub儲存函式庫進行掃描：

docker run zricethezav/gitleaks --repourl=https://github.com/chrisbinnie/CloudNativeSecurity

該命令將掃描https://github.com/chrisbinnie/CloudNativeSecurity儲存函式庫中的敏感資訊，並輸出發現的洩露資訊。

內容解密：

  • docker run zricethezav/gitleaks：執行Gitleaks的Docker容器。
  • --repourl=https://github.com/chrisbinnie/CloudNativeSecurity：指定要掃描的GitHub儲存函式庫URL。

自定義Gitleaks的輸出

Gitleaks提供了多個選項來自定義輸出。例如，使用--redact選項可以隱藏敏感資訊，使日誌不會被洩露的憑據汙染：

docker run zricethezav/gitleaks --repourl=https://github.com/chrisbinnie/CloudNativeSecurity --redact

內容解密：

  • --redact：隱藏輸出中的敏感資訊，以REDACTED代替。

以JSON格式輸出結果

使用-pretty選項，Gitleaks可以以格式化的JSON輸出發現的洩露資訊，便於在CI/CDPipeline中解析：

{
  "line": "aws_access_key_id = AKIAYEKNPWXOCW4YDEWX",
  "offender": "AKIAYEKNPWXOCW4YDEWX",
  "commit": "3c7c6639b9b7c34d5c192ef017e3047d2ac671d0",
  "repo": "CloudNativeSecurity",
  "rule": "AWS Manager ID",
  "commitMessage": "Add bad creds\n",
  "author": "Chris Binnie",
  "email": "chris@chrisbinnie.tld",
  "file": "secret_key.txt",
  "date": "2020–07–19T14:33:57+01:00",
  "tags": "key, AWS"
}

內容解密：

  • -pretty：以格式化的JSON輸出結果。
  • JSON輸出包含洩露資訊的詳細資訊，如行號、提交雜湊、檔案路徑等。

將Gitleaks整合到CI/CD流程

Gitleaks可以整合到單元測試、整合測試或作為預提交鉤子執行。此外，還可以定期掃描所有儲存函式庫，以發現潛在的安全問題。

Plantuml圖示：Gitleaks整合到CI/CD流程

此圖示展示了Gitleaks如何整合到CI/CD流程中，以自動掃描程式碼中的敏感資訊。

探索Gitleaks的其他功能

Gitleaks還支援許多其他選項，如掃描特定的提交或檔案。鼓勵使用者根據自己的需求調整Gitleaks的組態。

強化 Git 儲存函式庫的安全性：GitRob 的安裝與使用

在開發過程中，開發者不小心將敏感資訊（如金鑰、憑證、存取金鑰和密碼）推播到程式碼儲存函式庫的風險極高。因此，監控儲存函式庫以避免不必要的風險至關重要。本章將介紹 GitRob 這一開源工具，並探討其與 Gitleaks 在掃描能力上的差異。

安裝 GitRob

GitRob 可在 GitHub 上取得（github.com/michenriksen/gitrob）。使用者可選擇從原始碼編譯或使用預編譯的二進位制檔案。以下示範如何下載並驗證 Linux 版本的 GitRob：

  1. 下載 GitRob 二進位制檔案和校驗檔案

    $ wget https://github.com/michenriksen/gitrob/releases/download/v2.0.0-beta/gitrob_linux_amd64_2.0.0-beta.zip
$ wget https://github.com/michenriksen/gitrob/releases/download/v2.0.0-beta/checksums.txt

  2. 驗證下載檔案的完整性

    $ cat checksums.txt
$ sha256sum gitrob_linux_amd64_2.0.0-beta.zip

    確保 sha256sum 命令的輸出與 checksums.txt 中的對應值一致，以確認檔案未被篡改。

  3. 解壓縮 GitRob

    $ unzip gitrob_linux_amd64_2.0.0-beta.zip

    解壓後，目錄中將包含 gitrob 可執行檔和 README.md 說明檔案。

使用 GitRob 掃描儲存函式庫

在使用 GitRob 之前，需設定一個 GitHub 存取權杖（access token）作為環境變數：

$ export GITROB_ACCESS_TOKEN=9e3b27d7c382XXXXXXXXXXXXX96b1a45ea351c24

接著，執行 GitRob 掃描特定 GitHub 使用者的所有儲存函式庫：

$ ./gitrob chrisbinnie

程式碼解析：

$ ./gitrob chrisbinnie

此命令會初始化 GitRob，並開始掃描 chrisbinnie 在 GitHub 上的所有儲存函式庫。

內容解密：

  1. ./gitrob：執行當前目錄下的 GitRob 可執行檔。
  2. chrisbinnie：指定要掃描的 GitHub 使用者名稱。
  3. 掃描邏輯：GitRob 會克隆該使用者的所有儲存函式庫，並根據預設規則搜尋敏感資訊。

結果分析

GitRob 成功掃描儲存函式庫並發現了一個包含 AWS CLI 憑證的檔案 .aws/credentials，而非預期的 secret_key.txt。這顯示了其預設規則可能側重於特定路徑和檔案名稱，而非內容比對。

GitRob 掃描流程

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Git 儲存函式庫安全防護實踐

package "安全架構" {
    package "網路安全" {
        component [防火牆] as firewall
        component [WAF] as waf
        component [DDoS 防護] as ddos
    }

    package "身份認證" {
        component [OAuth 2.0] as oauth
        component [JWT Token] as jwt
        component [MFA] as mfa
    }

    package "資料安全" {
        component [加密傳輸 TLS] as tls
        component [資料加密] as encrypt
        component [金鑰管理] as kms
    }

    package "監控審計" {
        component [日誌收集] as log
        component [威脅偵測] as threat
        component [合規審計] as audit
    }
}

firewall --> waf : 過濾流量
waf --> oauth : 驗證身份
oauth --> jwt : 簽發憑證
jwt --> tls : 加密傳輸
tls --> encrypt : 資料保護
log --> threat : 異常分析
threat --> audit : 報告生成

@enduml

此圖示說明瞭 GitRob 的基本掃描流程，包括驗證存取權杖、克隆儲存函式庫及搜尋敏感資訊。

最佳實踐

  1. 定期掃描：將儲存函式庫掃描納入 CI/CD 流程，定期檢查程式碼中的敏感資訊。
  2. 強化存取控制：限制對敏感儲存函式庫的存取許可權，並使用權杖而非密碼進行身分驗證。
  3. 多層防護：結合不同工具和策略，形成多層防護機制，以最大程度降低風險。

本章介紹了 GitRob 的安裝和使用方法，並分析了其與 Gitleaks 的差異。透過結合多種工具和方法，可以有效提升程式碼儲存函式庫的安全性，避免敏感資訊外洩。

自動化主機安全強化

在現代DevSecOps的世界中，一個經常被忽視的領域是底層主機的作業系統（OS）。對於企業級雲原生應用程式來說，僅僅關注主機上的套件更新是不夠的。在保護Linux伺服器時，有許多導向可以改進，相對於預設安裝。

為何主機安全至關重要

即使有多層網路保護（從Web應用防火牆到內容傳遞網路（CDN）），最終為應用程式提供服務的是容器本身。由於容器只是底層主機OS的延伸，因此如果沒有健全的主機安全態勢，容器和應用程式就會面臨風險。

使用CIS Benchmark進行安全強化

一個流行的自定義Linux安全性的方法是根據所選的Linux發行版，從CIS網站（www.cisecurity.org/cis-benchmarks）選擇正確的CIS Benchmark版本。遵循這些基準測試的建議無疑有助於實作更好的安全態勢。然而，需要注意的是，其中許多建議的更改可能會導致根據主機的服務中斷，甚至可能對整個主機造成問題，如果在未完全瞭解其影響的情況下實施。

CIS Benchmark的等級

CIS Benchmark提供不同的等級，例如Level 1和Level 2。Level 1被認為是「實用和謹慎」的，而Level 2則提供了更深入的防禦，但可能會對技術的效用或效能產生負面影響。因此，務必只套用您感到舒適且預期能改善安全性的規則。

自動化安全強化

在本章中，我們將探討在強化機器映像時可能關注的一些安全細節。我們將使用Ansible playbook自動執行這些任務，並將其縮小為稍後可以構建playbook的任務，以確保我們的伺服器得到強化。我們還將探討一次性強化練習，使用稱為冪等性的概念，即伺服器能夠傳回到精確的前一個或原始狀態。

Ansible任務結構

如何構建Ansible任務內容以及遵循CIS Benchmark的程度，在很大程度上取決於三個因素：

  • 您對線上服務的重視程度
  • 您有多少時間可以專注於改善Linux伺服器的安全態勢
  • 您對風險的承受能力

機器映像

透過收集多個任務，可以建立一個「playbook」，這是Ansible程式碼更常見的稱呼。包含多少任務、針對哪些主機執行以及任務內容將完全取決於您的需求。以AWS為例，我們可以使用Ansible playbook來執行Amazon Machine Image（AMI），以建立在整個estate中使用的機器映像。

加密EBS磁碟區

加密附加到AWS EC2例項的Elastic Block Storage（EBS）磁碟區是有好處的。這提供了「靜態資料」加密，這意味著被攔截的映像無法在沒有您的KMS金鑰的情況下被讀取。從2019年5月開始，AWS允許您選擇為所有EBS磁碟區啟用加密。

- name: 加密EBS磁碟區
  ec2_eni:
    state: present
    region: "{{ region }}"
    zone: "{{ zone }}"
    subnet_id: "{{ subnet_id }}"
    device_index: 0
    delete_on_termination: true
    security_groups: "{{ security_groups }}"
  register: nic

- name: 建立加密EBS磁碟區
  ec2_vol:
    state: present
    region: "{{ region }}"
    zone: "{{ zone }}"
    encrypted: yes
    volume_size: "{{ volume_size }}"
  register: ebs_volume

#### 內容解密：
1. 第一個任務使用`ec2_eni`模組建立一個網路介面，並將其註冊到`nic`變數中。
2. 第二個任務使用`ec2_vol`模組建立一個加密的EBS磁碟區，並將其註冊到`ebs_volume`變數中。
3. `encrypted: yes`引數確保EBS磁碟區被加密。
4. `volume_size: "{{ volume_size }}"`引數設定EBS磁碟區的大小。

自動化主機安全：使用Ansible強化Linux伺服器安全性

在現代的DevSecOps實踐中，自動化主機安全是確保基礎設施安全性的關鍵環節。AWS EBS磁碟區加密是保護資料安全的重要措施，而Ansible則是用於自動化組態管理的強大工具。本章將探討如何使用Ansible來強化Linux伺服器的安全性。

EBS磁碟區加密的演變

在AWS引入EBS加密功能之前，加密EBS磁碟區需要經過多個步驟：

  1. 選擇可靠的Amazon Marketplace AMI並建立EC2例項。
  2. 更新Linux套件，重啟並建立執行中的例項快照，以建立新的AMI。
  3. 複製快照並使用KMS金鑰進行加密。
  4. 從加密的快照建立新的EBS磁碟區。

AWS官方檔案（docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIEncryption.html）提供了更多關於EBS磁碟區加密的詳細資訊。

冪等性（Idempotency）的重要性

與其一次組態機器映像然後在整個Amazon EC2中分發，不如重複執行Ansible playbook來組態執行中的伺服器。這就涉及到了冪等性的概念。簡單來說，冪等性意味著無論執行多少次相同的操作，結果始終保持一致。在Ansible playbook的上下文中，這意味著組態伺服器以滿足組織需求，然後定期重新執行playbook，以復原任何對伺服器所做的更改，無論是CI/CD流程還是攻擊者造成的。

內容解密：

  • 重複執行playbook：定時重新執行Ansible playbook，以確保伺服器組態的一致性。
  • 復原更改：透過冪等性操作，復原任何未經授權的更改，保持伺服器的預期狀態。
  • 提高安全性：定期重置伺服器組態，可以減少攻擊者持久控制伺服器的機會。

使用Ansible進行主機安全組態

Ansible是一種強大的組態管理工具，可以用於自動化主機安全組態。以下是使用Ansible進行主機安全組態的一些關鍵步驟：

Ansible目錄結構


### Ansible目錄結構範例
使用`tree`命令可以清晰地展示Ansible目錄結構，如圖11.1所示。

組態檔案和任務

在tasks/目錄下，可以定義多個任務來強化伺服器的安全性。例如，在network.yml檔案中，可以包含一系列任務來強化網路堆積疊的安全性。


### network.yml範例
---
- name: 強化網路堆積疊安全性
  tasks:
    - name: 組態防火牆規則
      template:
        src: templates/iptables.j2
        dest: /etc/iptables/rules.v4
      notify: 重啟防火牆服務

內容解密：

  • tasks/目錄：用於存放各種任務定義檔案，如network.yml。
  • 範本變數：使用Jinja語言的變數，使組態檔案更加靈活。
  • CIS Benchmark參考：參考CIS Benchmark來選擇需要強化的安全組態專案。

強化SSH守護程式

SSH守護程式是伺服器的一個常見入口點，因此強化其安全性至關重要。以下是一些強化OpenSSH守護程式的措施：

ssh.yaml範例

---
- name: 強化SSH守護程式
  tasks:
    - name: 設定閒置登出時間
      lineinfile:
        dest: /etc/ssh/sshd_config
        regexp: "^ClientAliveInterval"
        line: "ClientAliveInterval 300"
        state: present
      notify: 重啟SSH服務

    - name: 禁止空密碼登入
      lineinfile:
        dest: /etc/pam.d/common-auth
        regexp: "^auth required pam_unix.so"
        line: "auth required pam_unix.so nullok_secure"
        state: present

    - name: 設定法律警告橫幅
      copy:
        content: "未經授權存取本系統將被起訴！"
        dest: /etc/issue.net
      notify: 重啟SSH服務

內容解密：

  • 設定閒置登出時間：透過設定ClientAliveInterval，可以在使用者閒置一段時間後自動登出。
  • 禁止空密碼登入：透過PAM組態，禁止使用空密碼進行身份驗證。
  • 法律警告橫幅：設定警告橫幅，以符合合規要求，警告未經授權的存取者。
玄貓 BlackCat

玄貓 BlackCat

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