內容搬運模式（Content Ferry）

斷網環境裡的所有外部依賴（套件、映像、工具、更新）都要經過一條可控的搬運路徑進入。這條路徑的設計決定了環境的安全性和維護效率。

搬運路徑的三種形態

離線媒介搬運：用 USB 隨身碟、外接硬碟或光碟把檔案從有網路的工作站搬進隔離網路。適合高安全環境（軍事、政府機密網路），搬運頻率通常是週或月級。每次搬運的內容要經過掃毒和完整性驗證。

1# 外部工作站：準備搬運包
2mkdir -p ferry/$(date +%Y%m%d)
3# 把需要的套件、映像、工具複製進去
4cp -r packages/ images/ tools/ ferry/$(date +%Y%m%d)/
5# 產生 checksum
6find ferry/$(date +%Y%m%d) -type f -exec sha256sum {} \; > ferry/$(date +%Y%m%d)/manifest.sha256

1# 隔離網路內：驗證搬運包完整性
2cd /mnt/usb/ferry/20260626
3sha256sum -c manifest.sha256

跨網段閘道搬運：在隔離網路的邊界放一台 staging gateway（跳板機），它有兩張網卡——一張連外部網路（或 DMZ）、一張連內部隔離網路。外部的內容先傳到閘道、經過掃描和審查後再推進內部。適合金融和工控環境，搬運頻率可以是日級。

閘道的安全約束：只允許特定的檔案類型通過、所有傳入的檔案經過掃毒、傳輸記錄要保留 audit log、閘道本身定期更新安全軟體。

單向資料二極體（Data Diode）：硬體層面只允許資料單向流動（外 → 內），物理上無法從內部網路傳資料出去。用在最高安全等級的環境。搬運頻率和內容由二極體的設定決定。

搬運的操作紀律

每次搬運都要記錄：日期、搬運者、搬運內容清單（檔名 + 版本 + checksum）、搬運理由。這份紀錄存在內部網路的版本控制裡，讓「這個套件是誰、什麼時候、為什麼帶進來的」事後可追溯。

搬運內容的安全審查至少包含：掃毒（ClamAV 或商業掃毒）、checksum 驗證（確認搬運過程沒有被竄改）、版本確認（確認搬進來的版本跟預期的一致、不是被降級的舊版）。

時程參考：建立搬運流程（含閘道設定、掃描工具安裝、紀錄模板）約需 2-3 天。之後每次搬運操作約 1-2 小時（含準備、掃描、驗證、紀錄）。

離線套件管理

連網環境的 apt install、yum install、npm install 背後都在連線到公開的套件倉庫。斷網環境需要在內部建立這些倉庫的離線鏡像。

作業系統套件

Debian/Ubuntu：用 apt-mirror 或 aptly 在有網路的環境建立 mirror，把整個 mirror 搬進內部網路，內部機器的 /etc/apt/sources.list 指向內部 mirror。

1# 外部：建立 mirror（首次約 50-200GB，後續增量）
2apt-mirror /etc/apt/mirror.list
3
4# 內部：設定 sources.list 指向內部 mirror
5echo "deb http://internal-mirror.local/ubuntu jammy main restricted" > /etc/apt/sources.list
6apt update

RHEL/CentOS：用 reposync 把 yum repo 同步到本地，搬進內部後用 createrepo 建立 repo metadata。

1# 外部：同步 repo
2reposync --repoid=baseos --download-metadata -p /path/to/mirror/
3
4# 內部：建立 repo 並設定
5createrepo /path/to/mirror/baseos

應用層套件

Node.js（npm）：npm pack 把每個依賴打包成 .tgz，搬進內部後用 npm install --offline 或建立 Verdaccio private registry。

1# 外部：打包所有依賴
2npm pack --pack-destination ./offline-packages/
3# 或用 npm-offline-mirror
4npm install --prefer-offline --cache ./npm-cache

Python（pip）：pip download 把依賴下載成 wheel 或 tarball，搬進內部後 pip install --no-index --find-links=./packages/。

PHP（Composer）：composer install 後整個 vendor/ 目錄打包搬進去。或建立 Satis 作為 private Packagist mirror。

套件鏡像的維護節奏

離線 mirror 需要定期更新——安全補丁、版本升級都要透過搬運流程進入。更新頻率取決於安全需求：高安全環境至少月更（安全補丁）、一般環境季更可接受。每次更新都是一次搬運操作，要走完整的審查流程。

多格式統一：Nexus Repository

上面的做法是每個套件生態各自建 mirror（apt-mirror + Verdaccio + Satis + pip local index）。Nexus Repository 是多格式統一的 artifact proxy，同時支援 apt / yum / npm / Maven / PyPI / Docker / Helm——在企業級斷網環境裡，用一個 Nexus 實例取代多個獨立的離線 repo mirror，維護成本較低。代價是 Nexus 本身的安裝和維運（Java 應用、需要磁碟空間和記憶體），小團隊各自建 mirror 可能反而更簡單。

離線 Configuration Management：Ansible

斷網環境的 OS 設定、套件安裝、服務啟動等 configuration management 需求，Ansible 是運作良好的工具——它不需要在目標機器安裝 agent、透過 SSH 推送 playbook 執行，playbook 本身是 YAML 可版本控制。在沒有雲端 IaC（Terraform 管的是雲端資源 API）的地端斷網環境裡，Ansible 負責 configuration management 層。Ansible 自身的安裝只需要 Python，控制端安裝後即可透過 SSH 管理內部所有機器。

變更追蹤：沒有 GitHub 怎麼辦

斷網環境不能 push 到 GitHub、不能開 PR、不能用 GitHub Actions。但 git 本身是離線工具——git 的所有操作（commit、branch、merge、log、diff）都不需要網路。

內部 Git Server

在隔離網路內架設 git server：Gitea（輕量、單一二進位、適合小團隊）、GitLab CE（功能完整、含 CI/CD runner、適合中大團隊）、或最簡單的 bare repo on NFS。

1# 最簡單的方式：bare repo on 共用檔案系統
2git init --bare /shared/repos/infra.git
3
4# 開發者 clone
5git clone /shared/repos/infra.git

Git Bundle 跨網段傳遞

如果需要在有網路的環境開發、完成後搬進隔離網路，用 git bundle 把 commit 打包成單一檔案：

1# 外部：把 main branch 的所有 commit 打包
2git bundle create infra-$(date +%Y%m%d).bundle main
3
4# 搬運後，在內部 clone 或 pull
5git clone infra-20260626.bundle infra-repo
6# 或增量更新
7git pull infra-20260626.bundle main

bundle 檔案可以用 git bundle verify 驗證完整性。增量 bundle（只包含某個 tag 之後的 commit）可以減少搬運的資料量：

1git bundle create incremental.bundle last-imported-tag..main

Code Review 的替代方案

沒有 GitHub PR，code review 可以用：

• GitLab CE / Gitea 的內建 merge request（如果架了內部 git server）
• git format-patch 產出 patch 檔 + email review（傳統做法、不需要 web UI）
• git diff main..feature | less 直接在終端機 review（最簡陋但可行）

Staging Gateway 的設計

staging gateway 是搬運路徑的關鍵節點——它決定了什麼能進、什麼不能進。設計要點：

最小安裝：閘道上只裝搬運需要的工具（scp、rsync、掃毒軟體、checksum 工具），不裝開發工具、不跑應用服務。攻擊面越小越好。

雙網卡隔離：一張網卡連外部（或 DMZ）、一張連內部。兩張網卡之間沒有自動路由——檔案必須經過人工或腳本從外部目錄搬到內部目錄，中間經過掃描。

審計紀錄：閘道上的所有檔案操作（建立、複製、刪除）都要記錄。auditd 或等價工具提供核心層級的操作追蹤。

定期輪替：閘道本身的 OS 和掃毒軟體需要更新。這是一個遞迴問題（用什麼搬運閘道的更新？）——通常用離線媒介搬運閘道自身的更新，或用另一台更上游的閘道。

時程參考：閘道的初次設定（含 OS 安裝、雙網卡配置、掃描工具、審計設定）約需 1-2 天。搬運流程文件化約需半天。

安全審查：什麼能跨越隔離邊界

每一筆跨越隔離邊界的內容都是潛在的攻擊向量。審查的原則是：預設拒絕，逐項允許。

審查清單：

對決策者的重點：斷網環境的安全不是「隔離就安全」——搬運路徑是唯一的攻擊面，這條路徑的安全審查品質決定了整個隔離環境的安全水位。

跨分類引用

• → 斷網環境的 IaC：Terraform provider 和 module 的離線管理
• → 斷網環境的容器管理：映像搬運用的是本篇的 content ferry 模式
• → 模組八：治理好習慣：斷網環境的搬運紀錄是治理的一部分

Provider 離線管理

Provider Mirror

Terraform 的 providers mirror 指令在有網路的環境把指定 provider 的二進位檔下載到本地目錄，產出符合 filesystem mirror 結構的檔案：

 1# 在有網路的工作站執行
 2mkdir -p /path/to/mirror
 3terraform providers mirror -platform=linux_amd64 /path/to/mirror
 4
 5# mirror 目錄結構
 6# /path/to/mirror/
 7# └── registry.terraform.io/
 8#     └── hashicorp/
 9#         └── aws/
10#             └── 5.50.0/
11#                 └── terraform-provider-aws_5.50.0_linux_amd64.zip

把整個 mirror 目錄搬進隔離網路後，在 Terraform 設定裡指定 filesystem mirror：

 1# ~/.terraformrc 或 terraform.rc（Windows）
 2provider_installation {
 3  filesystem_mirror {
 4    path    = "/opt/terraform/providers"
 5    include = ["registry.terraform.io/*/*"]
 6  }
 7  direct {
 8    exclude = ["registry.terraform.io/*/*"]
 9  }
10}

direct 區塊的 exclude 確保 Terraform 不會嘗試連網下載——如果 mirror 裡沒有某個 provider，init 會直接報錯而非 hang 在網路連線。

Plugin Cache

替代 mirror 的另一個做法是 plugin cache directory。在有網路的環境跑過 init 後，.terraform/providers/ 裡會有已下載的 plugin。把這整個目錄搬進隔離網路，用 TF_PLUGIN_CACHE_DIR 環境變數指向它：

1export TF_PLUGIN_CACHE_DIR="/opt/terraform/plugin-cache"
2terraform init

mirror 跟 plugin cache 的差別：mirror 是正式的離線分發機制（有版本結構、支援多平台）、plugin cache 是快取機制（省重複下載、但目錄結構跟 mirror 不同）。長期運作用 mirror，臨時驗證用 cache。

Provider 版本鎖定

斷網環境的 provider 版本管理比連網更嚴格——升級一個 provider 代表要重新搬運整個 provider binary。在 versions.tf 裡鎖定精確版本（= 5.50.0 而非 ~> 5.50），避免 init 期待一個 mirror 裡沒有的版本：

1terraform {
2  required_providers {
3    aws = {
4      source  = "hashicorp/aws"
5      version = "= 5.50.0"
6    }
7  }
8}

Module 離線來源

連網環境的 module source 常指向 Terraform Registry 或 GitHub：source = "terraform-aws-modules/vpc/aws"。斷網環境要改成本地路徑或內部 git server。

本地路徑

最簡單——module 放在同一個 repo 或共用檔案系統的目錄裡：

1module "network" {
2  source = "../../modules/network"
3}

內部 Git Server

如果有架 Gitea 或 GitLab CE（見斷網通用原則），module 可以指向內部的 git repo：

1module "network" {
2  source = "git::http://gitea.internal/infra/modules.git//network?ref=v1.2.0"
3}

ref=v1.2.0 鎖定版本。內部 git server 的 module repo 用 git bundle 從外部搬運更新。

State Backend：沒有 S3 時的替代

連網環境的 state 通常放 S3 + DynamoDB lock。斷網環境如果沒有 AWS（地端機房或隔離網路），state backend 的替代選項：

最常見的組合是 PostgreSQL backend——多數環境已經有 PostgreSQL，不需要額外裝服務：

1terraform {
2  backend "pg" {
3    conn_str = "postgres://terraform:password@db.internal/terraform_state?sslmode=disable"
4  }
5}

PostgreSQL backend 的 lock 機制用 PostgreSQL 的 advisory lock，多人同時 apply 時第二個人會被擋住。

state 的備份紀律不變——定期 terraform state pull > backup.json，backup 存在版本控制或另一台機器上。

Plan / Apply 流程

斷網不影響 plan 和 apply 的執行——它們操作的是本地 provider 和目標基礎設施（地端伺服器、內部雲、VMware vSphere 等）。影響的是 provider 初始化和 module 取得，這些在前面幾節已處理。

沒有雲端 API 的情境

如果基礎設施不是雲端（地端 VMware、OpenStack、裸機），Terraform 有對應的 provider：

• VMware vSphere：hashicorp/vsphere
• OpenStack：terraform-provider-openstack/openstack
• Proxmox：telmate/proxmox（社群維護）
• 裸機管理：用 null_resource + local-exec 呼叫 Ansible 或 shell script

provider 的離線管理方式相同——mirror 或 plugin cache。

Plan 輸出的離線 Review

沒有 GitHub PR 的環境，plan 輸出用檔案分享 review：

1# 產出 plan 並存成可讀格式
2terraform plan -out=plan.tfplan
3terraform show plan.tfplan > plan-review-$(date +%Y%m%d).txt
4
5# 把 review 檔放到內部共用位置供 reviewer 閱讀
6cp plan-review-*.txt /shared/reviews/

reviewer 讀完後以 email、內部 chat、或直接在 review 檔旁邊放一個 approved-by-alice-20260626.txt 標記核准。不優雅但可追溯。

內網 CI/CD

斷網環境的 CI/CD 用自架的 CI server：

CI server 本身也需要離線安裝——GitLab CE 有 offline 安裝指南（.deb / .rpm 包）、Gitea 是單一二進位。CI runner 執行 Terraform 時使用內部的 provider mirror 和 module source。

CI workflow 的離線版本跟連網版本結構相同（init → fmt → validate → plan → review → apply），差別在 init 用 -plugin-dir 而非連網下載。

時程參考：內網 CI server 的初次建置（含 git server + CI runner + Terraform 離線環境）約需 3-5 天。之後的維護主要是 provider 版本更新的搬運（每次 1-2 小時）。

跨分類引用

• → 斷網環境的通用原則：provider 和 module 的搬運走 content ferry 模式
• → 模組一：最小可行 IaC：連網環境的 IaC 選型和 state 管理
• → 模組七：infra 走 PR 流程：連網環境的 CI pipeline 設定

Private Registry

隔離網路裡需要一個容器映像倉庫，讓內部的 Docker host / Kubernetes 節點能 pull image。

Harbor

Harbor 是 VMware 開源的企業級 registry，功能包含：映像儲存、漏洞掃描（整合 Trivy）、存取控制（RBAC）、映像簽章（Cosign / Notary）、複製策略。適合中大規模的斷網環境。

離線安裝：Harbor 提供 offline installer（.tgz，約 600MB），包含所有需要的容器映像。搬進隔離網路後解壓、跑 install.sh。

1# 外部：下載 offline installer
2wget https://github.com/goharbor/harbor/releases/download/v2.11.0/harbor-offline-installer-v2.11.0.tgz
3
4# 搬運後，在內部解壓安裝
5tar xzf harbor-offline-installer-v2.11.0.tgz
6cd harbor
7cp harbor.yml.tmpl harbor.yml
8# 編輯 harbor.yml：設定 hostname、HTTPS 憑證、admin 密碼
9./install.sh

Docker Registry（官方輕量版）

如果不需要 Harbor 的進階功能（RBAC、掃描），官方的 Docker Registry 是單一容器、設定最簡單：

1# registry image 也要先搬進來
2docker load < registry-2.8.3.tar
3docker run -d -p 5000:5000 --restart=always --name registry \
4  -v /data/registry:/var/lib/registry \
5  registry:2.8.3

內部機器的 Docker daemon 要設定信任這個 registry（如果是 HTTP 而非 HTTPS）：

1{
2  "insecure-registries": ["registry.internal:5000"]
3}

映像搬運

docker save / load

最直接的搬運方式——把映像匯出成 tar 檔、搬運後匯入：

1# 外部：匯出
2docker pull nginx:1.25-alpine
3docker save nginx:1.25-alpine -o nginx-1.25-alpine.tar
4
5# 搬運後，內部匯入
6docker load < nginx-1.25-alpine.tar
7# 重新 tag 指向內部 registry
8docker tag nginx:1.25-alpine registry.internal:5000/nginx:1.25-alpine
9docker push registry.internal:5000/nginx:1.25-alpine

多個映像可以打包成一個 tar：docker save img1 img2 img3 -o bundle.tar。

skopeo copy

skopeo 是不需要 Docker daemon 的映像操作工具，適合 CI 環境或沒有裝 Docker 的工作站：

1# 外部：從 Docker Hub 複製到本地目錄
2skopeo copy docker://nginx:1.25-alpine dir:/path/to/export/nginx-1.25
3
4# 搬運後，從本地目錄推送到內部 registry
5skopeo copy dir:/path/to/export/nginx-1.25 docker://registry.internal:5000/nginx:1.25-alpine

skopeo 的優勢是不需要 pull 整個映像到本地 Docker（省磁碟空間）、支援 OCI layout、且可以在沒有 root 權限的環境執行。

搬運清單管理

映像搬運容易變成「需要什麼才搬什麼」的臨時操作。建議維護一份搬運清單（manifest），列出所有需要的 base image 和版本：

 1# image-manifest.yaml
 2images:
 3  - name: nginx
 4    tag: 1.25-alpine
 5    source: docker.io/library/nginx
 6  - name: postgres
 7    tag: "16.3"
 8    source: docker.io/library/postgres
 9  - name: node
10    tag: 20-alpine
11    source: docker.io/library/node

搬運腳本讀這份清單自動 pull + save，確保每次搬運的內容一致且可追蹤。

Base Image 更新週期

斷網環境的 base image 不會自動更新——nginx:1.25-alpine 搬進去之後就是那個版本，裡面的 Alpine 套件不會收到安全補丁。需要定期用新版 base image 替換舊的。

更新流程

1. 外部：pull 最新版 base image
2. 外部：用 Trivy 掃描漏洞（見下一節）
3. 搬運：走 content ferry 帶進內部
4. 內部：push 到內部 registry、更新 tag
5. 內部：重新 build 所有依賴這個 base image 的應用映像
6. 內部：部署更新後的應用映像

更新頻率：安全敏感環境月更、一般環境季更。每次更新都要記錄哪些 base image 換了、從哪個版本換到哪個版本。

Helm Chart 離線

如果內部有 Kubernetes 且使用 Helm，chart 也要離線管理：

1# 外部：下載 chart
2helm pull bitnami/postgresql --version 15.5.0
3
4# 搬運後，內部用本地檔案安裝
5helm install pg ./postgresql-15.5.0.tgz -f values.yaml

或架設 ChartMuseum 作為內部 Helm repo：chart 搬進來後 push 到 ChartMuseum，helm repo add 指向它。

離線漏洞掃描

連網環境的 Trivy 會自動下載漏洞資料庫（CVE DB）。斷網環境要先在外部下載 DB、搬進來。

1# 外部：下載 Trivy 漏洞資料庫
2trivy image --download-db-only --cache-dir /path/to/trivy-db/
3
4# 搬運 DB 檔案（~30MB）
5# db.tar.gz 在 /path/to/trivy-db/db/ 裡
6
7# 內部：用離線 DB 掃描
8trivy image --skip-db-update --cache-dir /path/to/trivy-db/ registry.internal:5000/nginx:1.25-alpine

掃描結果的處理方式跟連網環境相同——critical 和 high 的 CVE 要評估是否影響、是否有 base image 更新可修。差別是斷網環境的修復週期更長（要走搬運流程），所以掃描要更頻繁（至少跟 base image 更新同步）。

Harbor 整合 Trivy 後可以在 push 時自動掃描——Trivy DB 的更新同樣需要定期搬運。

時程參考：Private registry 建置（Harbor offline）約需 1 天。映像搬運流程建立約需半天。第一批 base image 搬運 + 掃描約需半天。之後每次更新約 2-4 小時。

跨分類引用

• → 斷網環境的通用原則：映像搬運走 content ferry 模式
• → 模組五：核心服務上 IaC — 運算：連網環境的容器部署
• → ECS 知識卡：容器編排的基礎概念

Metric 收集：Prometheus + Grafana

Prometheus 是 pull-based 的 metric 收集系統——它主動去 scrape 各服務的 metric endpoint，不需要服務往外推資料。這個架構天然適合斷網：所有流量都在內網、不需要出站連線。

離線安裝

Prometheus 和 Grafana 都是單一二進位或容器映像，離線安裝跟映像搬運相同的流程：

1# 外部：下載 release binary
2wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz
3wget https://dl.grafana.com/oss/release/grafana-11.1.0.linux-amd64.tar.gz
4
5# 搬運後解壓、設定 systemd service
6tar xzf prometheus-2.53.0.linux-amd64.tar.gz
7sudo mv prometheus-2.53.0.linux-amd64 /opt/prometheus

如果用容器部署，先把映像搬進內部 registry 再 pull：

1# 內部：從內部 registry 啟動
2docker run -d -p 9090:9090 \
3  -v /etc/prometheus:/etc/prometheus \
4  -v /data/prometheus:/prometheus \
5  registry.internal:5000/prometheus:v2.53.0

Scrape 設定

Prometheus 的 prometheus.yml 定義要 scrape 的目標。斷網環境通常用 static config（手動列出目標）而非 service discovery（需要雲端 API）：

 1scrape_configs:
 2  - job_name: 'node-exporter'
 3    static_configs:
 4      - targets:
 5          - 'server-01:9100'
 6          - 'server-02:9100'
 7          - 'db-01:9100'
 8
 9  - job_name: 'app'
10    static_configs:
11      - targets:
12          - 'app-01:8080'
13          - 'app-02:8080'
14    metrics_path: '/metrics'

新增機器時手動把它加進 targets 清單。如果用 Consul（內網 service discovery），Prometheus 支援 Consul SD、可以自動發現新服務。

Node Exporter

每台需要監控的 Linux 機器裝一個 node_exporter（單一二進位、無依賴），暴露 CPU、記憶體、磁碟、網路等系統 metric。離線安裝同理——下載 binary、搬運、解壓、設成 service。

1# 搬運後安裝
2tar xzf node_exporter-1.8.1.linux-amd64.tar.gz
3sudo cp node_exporter-1.8.1.linux-amd64/node_exporter /usr/local/bin/
4sudo useradd --no-create-home --shell /bin/false node_exporter
5# 建立 systemd service（略）

Log 收集：Loki 或 ELK

Grafana Loki（輕量）

Loki 是 Grafana 生態的 log 彙整系統，架構類似 Prometheus（pull/push 都支援），但儲存的是 log stream 而非 metric。它不索引 log 內容（只索引 label），所以儲存成本遠低於 Elasticsearch。

 1# loki-config.yaml 基本設定
 2auth_enabled: false
 3server:
 4  http_listen_port: 3100
 5storage_config:
 6  filesystem:
 7    directory: /data/loki/chunks
 8schema_config:
 9  configs:
10    - from: 2024-01-01
11      store: tsdb
12      object_store: filesystem
13      schema: v13
14      index:
15        prefix: index_
16        period: 24h

搭配 Promtail（log 收集 agent）在每台機器上收集 log 並推送到 Loki：

 1# promtail-config.yaml
 2clients:
 3  - url: http://loki.internal:3100/loki/api/v1/push
 4scrape_configs:
 5  - job_name: system
 6    static_configs:
 7      - targets: [localhost]
 8        labels:
 9          job: syslog
10          __path__: /var/log/*.log

ELK Stack（功能豐富）

Elasticsearch + Logstash + Kibana 是功能最完整的 log 平台，但資源消耗大（Elasticsearch 建議至少 4GB RAM 起跳）。適合需要全文搜索 log 內容的場景。

離線安裝：Elastic 提供離線安裝包（.deb / .rpm），或用 Docker 映像。三個組件都要搬運。

選型判準：5 台以下的小環境用 Loki（輕量、跟 Prometheus + Grafana 同一套 dashboard）。需要全文搜索、已有 ELK 經驗的團隊用 ELK。

告警：沒有外部 webhook 怎麼通知

連網環境的告警通常發到 Slack webhook、PagerDuty API、或 email relay service。斷網環境這些路徑都不通。

內部 SMTP

如果隔離網路內有 email server（很多企業內網有 Exchange 或 Postfix），Prometheus Alertmanager 可以發 email 告警：

 1# alertmanager.yml
 2route:
 3  receiver: 'email-team'
 4receivers:
 5  - name: 'email-team'
 6    email_configs:
 7      - to: 'oncall@internal.corp'
 8        from: 'alertmanager@internal.corp'
 9        smarthost: 'smtp.internal.corp:25'
10        require_tls: false

內部即時通訊

如果內網有 Mattermost（Slack 的 self-hosted 替代）或 Rocket.Chat，Alertmanager 可以用 webhook 發送到這些工具的 incoming webhook endpoint。

實體告警

極端情境（沒有 email、沒有 chat）：Alertmanager 把告警寫到檔案或資料庫、搭配值班制度定期查看。或用 Grafana 的 dashboard + 控制室大螢幕，值班人員直接看板。

告警的設計原則跟連網環境相同——symptom-based（錯誤率、延遲）優先於 cause-based（CPU、記憶體），閾值設計避免告警疲勞。差別在通知的到達速度可能慢一些（email 比 Slack push 慢），所以閾值要稍微保守（提早告警）。

Metric 與 Log 的儲存規劃

SaaS 監控的儲存是雲端自動擴展的。Self-hosted 的儲存要自己規劃——磁碟滿了 Prometheus 就停止收集、Loki 就停止寫入。

容量估算

Prometheus 的儲存量取決於 series 數量 × scrape 間隔 × 保留天數。粗估公式：

1每日儲存 ≈ active_series × sample_size(2B) × (86400 / scrape_interval) × compression_ratio(~0.1)

1 萬個 active series、15 秒 scrape interval、保留 30 天 ≈ 約 5GB。保留 90 天 ≈ 約 15GB。

Loki 的儲存量取決於 log 流量。粗估：每天 10GB 的 raw log 在 Loki 壓縮後約 1-2GB，保留 30 天 ≈ 30-60GB。

Retention 設定

1# prometheus.yml
2global:
3  scrape_interval: 15s
4storage:
5  tsdb:
6    retention.time: 30d
7    retention.size: 10GB  # 以先到的為準

超過容量時 Prometheus 自動刪除最舊的資料。設定 retention 前先確認磁碟空間足夠——斷網環境擴容磁碟的流程（採購 + 安裝）可能需要週到月級的時間。

NTP 時間同步

斷網環境容易被忽略的一個問題是時間同步。沒有 NTP server（pool.ntp.org）可連的機器，時鐘會漂移——幾天後各台機器的時間差可能達到秒級。當 Prometheus 收到的 metric timestamp 跟 Loki 收到的 log timestamp 有幾秒落差，事故排查時 metric 跟 log 對不上。

解法是在隔離網路內架一台 NTP server，所有機器從它同步：

1# 內部 NTP server（chrony）
2# /etc/chrony/chrony.conf
3local stratum 10         # 沒有外部來源時、自己當 stratum 10
4allow 10.0.0.0/16        # 允許內部網段同步
5
6# 其他機器指向內部 NTP
7server ntp.internal iburst

如果隔離網路的閘道可以開 NTP（UDP 123），讓閘道從外部 NTP 同步、內部機器從閘道同步，時間精度可以維持在毫秒級。

時程參考：Prometheus + Grafana + Alertmanager 的初次建置約需 1-2 天。Loki + Promtail 約需半天到一天。NTP server 約需 2 小時。後續維護主要是 Prometheus/Loki 版本更新的搬運（每次 1-2 小時）和儲存容量監控。

跨分類引用

• → 斷網環境的通用原則：監控工具的離線安裝走 content ferry 模式
• → 斷網環境的容器管理：Prometheus/Grafana/Loki 的容器映像搬運
• → 模組六：可觀測性與 log：連網環境的可觀測性 IaC
• → 無 SSH 環境的監控與告警：另一個極端——完全外部監控
• → Monitoring 04：Collector 架構與部署：SDK 和 Collector 的應用層監控，斷網環境需要把 Collector endpoint 指向 self-hosted backend
• → Monitoring 06：Self-hosted vs Commercial：斷網環境只能走 self-hosted 路線

斷網環境裡這些服務全部要自建。每一個 SaaS 變成一個內部服務，infra 團隊承擔它的部署、設定、升級、備份、監控和使用者管理。這篇文章盤點完整的服務清單、推薦的自建工具、部署順序，以及容易被低估的維護成本。

服務清單與選型

「部署複雜度」指首次部署到可用狀態的工程量。「維護頻率」指部署完成後的持續性工作——安全更新、容量擴充、故障排查。

各服務的選型判斷

版本控制：GitLab CE 功能完整（含 CI/CD、container registry、package registry），但資源消耗大（建議 4 核 / 8GB 以上）。Gitea 輕量（512MB 記憶體可跑），適合小團隊或只需要 Git hosting 的情境。如果選 GitLab CE，版控 + CI/CD + registry 可以用同一個實例，減少部署數量。

CI/CD：如果已部署 GitLab CE，內建的 GitLab CI 是最低成本的選擇——Runner 裝在同一網段的機器上即可。Jenkins 的生態更大（plugin 多），但 plugin 的離線安裝和更新需要額外的搬運流程。

套件 registry：Nexus Repository 是斷網環境的首選，因為它用一個實例同時支援 apt / yum / npm / Maven / PyPI / Docker / Helm——維護一個服務取代六個獨立的離線 repo mirror。Artifactory 是商業替代品，功能相似但需要授權費。

容器 registry：Harbor 提供映像掃描（整合 Trivy）、RBAC、複寫、稽核 log。如果只需要儲存和拉取映像、不需要掃描和稽核，Docker Registry（開源）足夠。

內部 CA：step-ca 支援 ACME 協定（跟 Let’s Encrypt 相同的自動簽發流程），內部服務可以用跟外部一樣的 certbot 工具自動續期。cfssl 是更輕量的選擇但沒有 ACME 支援、需要手動或腳本續期。

內部 DNS：CoreDNS 用設定檔驅動、輕量、適合 Kubernetes 環境。BIND 是傳統選擇、功能完整但設定複雜。多數斷網環境的 DNS 需求簡單（幾十筆 A record），CoreDNS 的 file plugin 足夠。

時間同步：chrony 是 NTP 的現代替代——啟動快、適應性強、低資源。內網裡指定一台機器當 NTP server（stratum 1 如果有 GPS 時鐘、stratum 2 如果手動校時），其他機器指向它。時間不同步會讓 log correlation 失效、TLS 憑證驗證失敗、Kerberos 認證拒絕。

監控：Prometheus（metric 收集）+ Grafana（視覺化）+ Loki（log 聚合）是最常見的 self-hosted 監控組合。三者都支援離線部署、不需要外部依賴。詳見斷網環境的監控與可觀測性。

機密管理：HashiCorp Vault 提供 secret 儲存、動態 secret 產生、PKI、加密即服務。部署和維護複雜度高——Vault 本身需要 unseal、HA 需要 Raft 或 Consul 後端、稽核 log 需要儲存規劃。如果機密數量少且變更不頻繁，加密的 ansible-vault 或 git-crypt 是輕量替代。

IaC state 後端：PostgreSQL 是 Terraform 支援的 state backend 之一（backend "pg"），斷網環境裡用既有的 PostgreSQL 實例存 state、用 PostgreSQL 的 advisory lock 防並行。比自建 S3 + DynamoDB 簡單得多。Consul 是另一個選擇（Terraform 原生支援），但引入 Consul 只為了存 state 的 ROI 通常不划算、除非環境裡已經有 Consul 跑 service discovery。

部署順序

服務之間有依賴關係，部署順序由依賴方向決定：

 1第一層（基礎設施服務）
 2  DNS → 所有服務都需要名稱解析
 3  NTP → 所有服務都需要時間同步
 4  CA  → 所有服務都需要 TLS 憑證
 5
 6第二層（開發平台服務）
 7  版本控制 → 程式碼要有地方存才能跑 CI
 8  套件 + 容器 registry → build 需要依賴
 9
10第三層（自動化服務）
11  CI/CD → 依賴版控 + registry
12  IaC state backend → Terraform 需要 state 存放處
13
14第四層（營運服務）
15  機密管理 → 其他服務的 secret 集中管理
16  監控 → 監控所有上述服務的健康

第一層的三個服務可以平行部署——它們彼此不依賴。第四層的監控放最後是因為它要監控的對象都還沒就位時、設定 target 沒有意義。

每一層部署完成後做一次整體驗證（所有服務能互相連通、TLS 正常、時間同步），再進下一層。

統一管理 vs 個別部署

GitLab CE 把版控、CI/CD、container registry、package registry 打包在一個實例裡。用 GitLab CE 取代四個獨立服務的優缺點：

小團隊（5-15 人）的斷網環境，GitLab CE 統一管理的 ROI 通常較高——維護一個服務比維護四個省力，故障半徑的風險靠備份和 HA（GitLab 支援 Geo replication）緩解。

大團隊或高安全環境，個別部署的隔離性較好——CI runner 跟版控分開、registry 跟 CI 分開，每個服務的存取控制和稽核獨立。

同樣的邏輯適用於 Nexus：它用一個實例服務 6 種格式的套件，比為每種格式各建一個離線 mirror 省力。

維護的隱藏成本

自建服務的維護成本容易被低估，因為部署完成時感覺「已經做完了」，但持續性維護才剛開始。每個自建服務需要：

10 個自建服務各自都有這六項維護需求。時程參考：每月的例行維護（安全更新 + 備份驗證 + 容量檢查）約需 2-3 天工程師時間。這筆時間是隱性的——不在任何 sprint 或 ticket 裡，但不做的後果是累積的。

管理層溝通時的關鍵數字：自建 10 個服務的維護成本約等於 0.3-0.5 個全職工程師。這筆人力投入是斷網環境的結構性成本，跟應用開發無關。

跨分類引用

• → 斷網環境的通用原則：內容搬運、離線套件管理的共通模式
• → 斷網環境的 IaC：state backend（PostgreSQL）和 CI 的詳細設定
• → 斷網環境的容器與映像管理：Harbor 和映像搬運的詳細操作
• → 斷網環境的監控與可觀測性：Prometheus + Grafana + Loki 的部署
• → 模組二：身分與憑證地基：Vault 的身分管理與 infra IAM 的關係
• → 模組八：治理好習慣：自建服務的 secret 管理與成本歸因

GitLab CE vs Gitea：選型判準

兩個主流的自建版本控制方案定位不同：

選型判準是團隊規模和需要的功能範圍。5 人以下、只需要 VCS + 輕量 CI 的團隊，Gitea + Drone 的組合維護成本低。10 人以上、需要 MR review + CI pipeline + Container Registry 一站到位的團隊，GitLab CE 的整合度值得它的資源消耗。

接下來以 GitLab CE 為主線說明（功能最完整），Gitea 的差異在各段附註。

GitLab CE 離線安裝

GitLab Omnibus 包把所有依賴打包成單一安裝檔，不需要在目標機器上 apt install 任何前置套件。

在外網機器下載安裝包

1# Ubuntu/Debian
2wget https://packages.gitlab.com/gitlab/gitlab-ce/packages/ubuntu/jammy/gitlab-ce_17.0.0-ce.0_amd64.deb/download.deb
3
4# RHEL/CentOS
5wget https://packages.gitlab.com/gitlab/gitlab-ce/packages/el/9/gitlab-ce-17.0.0-ce.0.el9.x86_64.rpm/download.rpm

把下載的 .deb 或 .rpm 透過內容搬運機制（USB、光碟、跨邊界傳輸站）帶進斷網環境。

在斷網機器安裝

1# Ubuntu/Debian
2sudo dpkg -i gitlab-ce_17.0.0-ce.0_amd64.deb
3
4# RHEL/CentOS
5sudo yum localinstall gitlab-ce-17.0.0-ce.0.el9.x86_64.rpm

離線設定

安裝後編輯 /etc/gitlab/gitlab.rb，把所有外部連線關掉：

 1# 設定內部域名（不是公網域名）
 2external_url 'https://gitlab.internal.example.com'
 3
 4# 關閉 Gravatar（頭像服務、需要外網）
 5gitlab_rails['gravatar_enabled'] = false
 6
 7# 關閉 usage ping（回報使用統計到 GitLab Inc）
 8gitlab_rails['usage_ping_enabled'] = false
 9
10# 關閉 version check
11gitlab_rails['gitlab_check_on_connect'] = false
12
13# 如果沒有內部 SMTP，用 sendmail 或關閉 email
14gitlab_rails['smtp_enable'] = false
15
16# TLS 憑證用內部 CA 簽發
17nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.crt"
18nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.key"

1sudo gitlab-ctl reconfigure

Gitea 的離線安裝更簡單：下載單一二進位檔 gitea、設定 app.ini、用 systemd 管理即可。

升級策略

GitLab CE 的升級包也要從外部下載帶進來。升級前先備份（gitlab-backup create），升級路徑要按 GitLab 的版本跳級規則——不能任意跳版、某些大版本之間需要中繼版本。在斷網環境裡，每次升級要預先規劃中繼版本、一次帶進所有需要的安裝包。

CI Runner 離線設定

CI pipeline 在斷網環境裡跑的最大差異是 runner 不能即時拉依賴。

Runner 安裝與註冊

1# 下載 runner 二進位檔（外網下載、帶進來）
2# https://docs.gitlab.com/runner/install/linux-manually.html
3
4sudo gitlab-runner register \
5  --url https://gitlab.internal.example.com \
6  --token $RUNNER_TOKEN \
7  --executor docker \
8  --docker-image alpine:3.20

Executor 選擇

斷網環境推薦 shell executor（最少依賴）或 docker executor 搭配預拉好的 image。

Docker executor 的 image 管理

Docker executor 的每個 job 都基於一個 base image。斷網環境裡這些 image 必須預先存在於內網的 private registry：

1# runner 的 /etc/docker/daemon.json 指向內部 registry
2{
3  "insecure-registries": ["registry.internal:5000"],
4  "registry-mirrors": ["https://registry.internal:5000"]
5}

CI pipeline 裡用到的每個 image（build 用的 golang/node/php、lint 用的 tflint/checkov、deploy 用的 awscli）都要事先搬進內部 registry。

依賴快取

沒有 npm registry / PyPI / Maven Central 可以拉，CI job 的依賴安裝必須用本地來源：

1# .gitlab-ci.yml — 使用內部 Nexus 作為套件來源
2variables:
3  NPM_CONFIG_REGISTRY: "https://nexus.internal/repository/npm-proxy/"
4  PIP_INDEX_URL: "https://nexus.internal/repository/pypi-proxy/simple/"

或者把 node_modules / vendor 打包成 CI artifact 快取，避免每次 job 都重新安裝。

Git Bundle 跨邊界傳輸

某些斷網環境不允許直接 git push 到內網 GitLab（例如開發在外網、部署在內網）。Git bundle 是把 commit 歷史打包成單一檔案的機制：

1# 外網開發機：打包最近的 commit
2git bundle create changes.bundle main~5..main
3
4# 帶進斷網環境後
5git bundle verify changes.bundle
6git fetch changes.bundle main:incoming
7git merge incoming

bundle 檔案包含完整的 Git 物件（commit、tree、blob），可以通過任何檔案傳輸方式帶過邊界——USB、光碟、審批後的檔案傳輸閘道。

跨邊界傳輸的安全考量：bundle 的內容應該在傳入前被掃描（至少 git bundle verify），確認不包含預期外的分支或異常大的物件。某些高安全環境要求所有跨邊界檔案經過人工審批。

MR Review 流程

斷網環境的 MR（Merge Request）review 流程跟模組七：infra 走 PR 流程的原則相同——變更走 MR → CI 跑 plan → reviewer 看 diff + plan 輸出 → 合併 → apply。差別在於所有環節都在內網：

 1# .gitlab-ci.yml — Terraform plan 貼回 MR comment
 2plan:
 3  stage: plan
 4  script:
 5    - terraform init -plugin-dir=/opt/terraform/plugins
 6    - terraform plan -no-color -out=plan.tfplan | tee plan.txt
 7    - |
 8      curl --request POST \
 9        --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
10        --data-urlencode "body=$(cat plan.txt)" \
11        "https://gitlab.internal/api/v4/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/notes"
12  only:
13    - merge_requests

GitLab CI 的 merge_requests trigger 跟 GitHub Actions 的 pull_request 等價——MR 開啟或更新時自動跑 pipeline。

reviewer 在 GitLab 的 MR 頁面看 code diff + plan 輸出 comment，approve 後合併，合併觸發 apply pipeline。流程跟有網路時完全相同，只是所有元件（GitLab、runner、Terraform、provider plugin）都在內網。

時程與維護

GitLab CE 的主要維護成本在升級——斷網環境的升級不能一鍵 apt upgrade，要預先下載正確版本的安裝包帶進來。跳版規則讓這個過程比正常環境多一層規劃。

跨分類引用

• → 斷網環境的通用原則：內容搬運、離線套件管理的共通模式
• → 斷網環境的容器與映像管理：CI runner 的 Docker image 管理
• → 模組七：infra 走 PR 流程：MR review 流程的原則與護欄

本篇涵蓋兩個 registry 的部署與操作：Nexus Repository（多格式套件）和 Harbor（容器映像）。兩者可以獨立運作，也可以搭配使用——Nexus 管套件依賴、Harbor 管容器映像，各自負責不同的 artifact 類型。

Nexus Repository：統一的離線套件 proxy

Nexus Repository OSS（開源版）支援 apt、yum、npm、PyPI、Maven、NuGet、Go modules 等多種格式，用一個實例取代多個獨立的離線 repo mirror。部署在內網後，所有開發機器和 CI runner 把套件 source 指向 Nexus。

部署

Nexus 本身是一個 Java 應用，用 Docker 部署最簡單。映像需要事先從外部搬進來：

1# 外部機器下載映像
2docker pull sonatype/nexus3:latest
3docker save sonatype/nexus3:latest -o nexus3.tar
4
5# 搬運到內網後載入
6docker load -i nexus3.tar
7docker run -d -p 8081:8081 --name nexus \
8  -v nexus-data:/nexus-data \
9  sonatype/nexus3:latest

初始管理員密碼在容器內 /nexus-data/admin.password，首次登入後強制修改。

Hosted repo 模式

連網環境的 Nexus 通常用 proxy repo（代理公開 registry、快取下載過的套件）。斷網環境 proxy 模式無法運作，改用 hosted repo——手動上傳套件到 Nexus，Nexus 作為唯一的分發來源。

以 npm 為例，workflow 是在外部機器打包、搬運、上傳：

 1# 外部機器：打包專案的所有依賴
 2npm pack --pack-destination ./npm-packages/
 3# 或用 npm-offline-packager 批次下載整棵依賴樹
 4npx npm-offline-packager --package ./package.json --output ./npm-packages/
 5
 6# 搬運到內網後上傳到 Nexus
 7for pkg in ./npm-packages/*.tgz; do
 8  curl -u admin:password \
 9    --upload-file "$pkg" \
10    "http://nexus.internal:8081/repository/npm-hosted/"
11done

apt 和 yum 的做法類似：外部機器用 apt-get download 或 yumdownloader 抓 .deb / .rpm 檔案，搬進來後上傳到 Nexus 的 hosted repo。

客戶端設定

開發機器和 CI runner 的套件 source 指向 Nexus：

1# npm
2npm config set registry http://nexus.internal:8081/repository/npm-hosted/
3
4# pip
5pip install --index-url http://nexus.internal:8081/repository/pypi-hosted/simple/ package-name
6
7# apt（在 /etc/apt/sources.list.d/ 加一份）
8deb http://nexus.internal:8081/repository/apt-hosted/ focal main

Harbor：容器映像的 private registry

Harbor 是 CNCF 畢業專案的企業級容器 registry，支援映像簽章、漏洞掃描（Trivy）、存取控制、映像複製。在斷網環境裡它是 Docker Hub 和 ECR 的替代品。

部署

Harbor 用 Docker Compose 部署。安裝包需要從外部下載後搬進來：

 1# 外部機器下載離線安裝包
 2wget https://github.com/goharbor/harbor/releases/download/v2.11.0/harbor-offline-installer-v2.11.0.tgz
 3
 4# 搬運到內網後解壓
 5tar xzf harbor-offline-installer-v2.11.0.tgz
 6cd harbor
 7
 8# 複製並編輯設定
 9cp harbor.yml.tmpl harbor.yml
10# 修改 hostname、storage 路徑、HTTPS 憑證（內部 CA 簽發）
11
12# 安裝
13./install.sh --with-trivy

--with-trivy 啟用內建的漏洞掃描。Trivy 的漏洞資料庫需要離線更新——從外部下載 DB 檔案、搬進來放到指定路徑。

專案與存取控制

Harbor 用「專案」（project）組織映像。每個專案可以設定獨立的存取控制：

• library：公開專案、所有使用者可 pull
• platform：平台團隊專用、限定成員可 push
• vendor：第三方 base image、由 infra 團隊管理更新

robot account 提供 CI/CD 用的非互動式認證（限定 pull / push 權限、可設定到期時間）。

映像搬運 SOP

映像從外部搬進斷網環境是一個需要標準化的操作，涉及格式、大小、多架構支援：

搬運工具比較

skopeo 的操作流程：

1# 外部機器：從 Docker Hub 複製到本地目錄
2skopeo copy docker://nginx:1.25-alpine dir:./images/nginx-1.25-alpine
3
4# 搬運到內網後：從本地目錄推到 Harbor
5skopeo copy dir:./images/nginx-1.25-alpine \
6  docker://harbor.internal/library/nginx:1.25-alpine \
7  --dest-tls-verify=false  # 如果 Harbor 用內部 CA

多架構映像

如果環境同時有 amd64 和 arm64 的機器，搬運時要帶整個 manifest list：

1# 外部：複製所有架構
2skopeo copy --all docker://nginx:1.25-alpine \
3  dir:./images/nginx-1.25-alpine-multiarch
4
5# 內網：推送所有架構
6skopeo copy --all dir:./images/nginx-1.25-alpine-multiarch \
7  docker://harbor.internal/library/nginx:1.25-alpine

--all flag 確保 manifest list 裡的每個架構都被複製，而非只複製本機架構。

套件與映像的更新週期

斷網環境的套件和映像不會自動更新——每一次更新都是一次有意識的搬運操作。更新週期的頻率由安全需求決定：

每次更新的標準流程：

1. 外部機器下載：按清單下載指定版本的套件和映像
2. 安全掃描：在外部（或 staging gateway）跑 Trivy / Snyk 掃描，確認沒有已知的高風險 CVE
3. 審查核准：掃描報告給安全團隊或負責人簽核
4. 搬運：核准的 artifact 寫入唯讀媒體或加密通道搬進內網
5. 上傳到 registry：推到 Nexus 和 Harbor
6. 通知團隊：哪些套件/映像有新版本可用

這個流程的產出是一份更新清單（什麼版本、掃描結果、核准人），存進版控作為稽核紀錄。

Helm chart 離線管理

Kubernetes 環境用 Helm 部署應用。斷網時 Helm chart 需要離線管理：

1# 外部機器：下載 chart
2helm repo add bitnami https://charts.bitnami.com/bitnami
3helm pull bitnami/postgresql --version 15.5.0
4
5# 搬運到內網後有兩個存放選項

選項一：Harbor 內建 chart 支援。Harbor 2.0+ 支援 OCI artifact，Helm chart 可以直接推到 Harbor：

1helm push postgresql-15.5.0.tgz oci://harbor.internal/charts

選項二：ChartMuseum。獨立的 chart repository server：

1# 上傳 chart
2curl --data-binary "@postgresql-15.5.0.tgz" \
3  http://chartmuseum.internal:8080/api/charts

Harbor 的 OCI 方式較簡單（不需要額外維護 ChartMuseum），但需要 Helm 3.8+ 的 OCI 支援。

時程與管理層溝通

管理層需要知道的成本：registry 的維護不是一次性投入，每個更新週期都需要工程師時間執行搬運和掃描。這筆成本在連網環境裡由公開 registry 和自動更新吸收，斷網環境裡由團隊承擔。

跨分類引用

• → 斷網環境的通用原則：content ferry pattern 和安全審查流程
• → 斷網環境的容器與映像管理：映像搬運的更完整討論（本篇聚焦 registry 部署、該篇聚焦映像生命週期）
• → 斷網環境的 IaC：Terraform provider 也需要離線 mirror、可用 Nexus 的 raw hosted repo 存放

Internal DNS：內部名稱解析

斷網環境沒有公開 DNS 可用。內部服務之間的互相引用（GitLab 連 PostgreSQL、Harbor 連 storage backend）如果靠 IP 位址，每次 IP 變動都要改一輪設定。內部 DNS 讓服務用 hostname（gitlab.internal、harbor.internal）互相引用，IP 變動只改 DNS zone 一處。

CoreDNS vs BIND

多數斷網環境用 CoreDNS 就夠——zone 檔案放在磁碟上、Corefile 幾行就能啟動。

最小設定

 1# Corefile
 2internal:53 {
 3    file /etc/coredns/zones/internal.zone
 4    log
 5    errors
 6}
 7
 8.:53 {
 9    forward . /dev/null
10    log
11}

第一個 block 處理 internal 域名的查詢、從 zone 檔案回應。第二個 block 攔截所有其他查詢——斷網環境不能轉發到上游 DNS，forward . /dev/null 讓非內部域名直接返回 NXDOMAIN 而非 timeout。

 1; /etc/coredns/zones/internal.zone
 2$ORIGIN internal.
 3@       IN SOA  ns1.internal. admin.internal. (
 4        2026062601 ; serial
 5        3600       ; refresh
 6        600        ; retry
 7        86400      ; expire
 8        60         ; minimum
 9)
10        IN NS   ns1.internal.
11ns1     IN A    10.0.1.10
12gitlab  IN A    10.0.1.20
13harbor  IN A    10.0.1.21
14vault   IN A    10.0.1.22
15nexus   IN A    10.0.1.23
16prom    IN A    10.0.1.24
17grafana IN A    10.0.1.25
18ntp     IN A    10.0.1.11

新增服務時加一行 A record、重載 CoreDNS（kill -SIGUSR1 $(pidof coredns) 或重啟 container）。serial 號遞增讓變更可追蹤。

客戶端設定

每台機器的 /etc/resolv.conf 指向 CoreDNS 的 IP：

1nameserver 10.0.1.10
2search internal

如果環境有 DHCP server，在 DHCP option 裡配 DNS server 位址，新加入的機器自動取得。沒有 DHCP 就靠 provisioning 腳本或 Ansible playbook 推送。

NTP：內部時間同步

時間不同步在斷網環境會引發三類問題：log 的時間戳錯亂讓事故排查無法跨機器對齊、TLS 憑證的有效期判斷出錯導致合法憑證被拒絕、以及 Kerberos 等時間敏感的認證協定直接失敗。正常環境從 pool.ntp.org 取得時間，斷網環境需要自己的時間源。

chrony 作為 NTP server

chrony 比傳統的 ntpd 更適合網路不穩或隔離的環境——它的時鐘修正演算法在長時間無外部時間源時仍能保持較準確的漂移補償。

1# /etc/chrony.conf（NTP server 端）
2# 斷網環境：沒有上游 NTP、用本機時鐘作為最後手段
3local stratum 10
4allow 10.0.0.0/8
5driftfile /var/lib/chrony/drift

local stratum 10 宣告「我自己是時間源、但 stratum 很低（精度不高）」。其他機器的 chrony 設定指向這台 server：

1# /etc/chrony.conf（客戶端）
2server ntp.internal iburst
3makestep 1.0 3

iburst 讓開機時快速同步、makestep 1.0 3 允許前三次校正時跳大步（修正啟動時的大偏差）。

高精度需求

如果環境對時間精度有要求（金融交易、工控系統），NTP server 需要硬體時間源——GPS 接收器或原子鐘模組。GPS 天線不需要網路連線、只需要看得到衛星的位置（屋頂或窗邊）。chrony 支援 PPS（Pulse Per Second）輸入、可以達到微秒級精度。

多數斷網環境不需要這個精度——毫秒級一致（chrony 預設行為）對 log 對齊和 TLS 驗證已經足夠。

Internal CA：內部憑證簽發

斷網環境的每個內部 HTTPS 服務都需要 TLS 憑證。Let’s Encrypt 的 ACME challenge 需要連網驗證，在斷網環境無法使用。替代方案是建立內部 CA（Certificate Authority），自己簽發憑證。

step-ca（Smallstep）

step-ca 是一個輕量的 CA server，支援 ACME 協定——內部服務可以用跟 Let’s Encrypt 相同的流程自動申請和續期憑證，只是 ACME server 是內網的 step-ca 而非 Let’s Encrypt。

1# 初始化 CA
2step ca init --name="Internal CA" --dns="ca.internal" \
3  --address=":443" --provisioner="admin"
4
5# 啟動 CA server
6step-ca $(step path)/config/ca.json

初始化會產生 root CA 和 intermediate CA 的 key pair。root CA 的私鑰是整個信任鏈的根——它的保護等級要最高（離線儲存、存取紀錄）。

憑證簽發流程

服務用 ACME client 向 step-ca 申請憑證：

1# 用 step CLI 申請憑證（手動方式）
2step ca certificate "gitlab.internal" gitlab.crt gitlab.key
3
4# 用 ACME 自動續期（搭配 certbot 或 step 的 renewal daemon）
5step ca renew --daemon gitlab.crt gitlab.key

certbot 也能配合 step-ca 使用——把 ACME server URL 從 Let’s Encrypt 改成 https://ca.internal/acme/acme/directory。已有 certbot 自動續期腳本的服務只要改一行設定。

Root CA 分發

每台機器和每個服務都要信任內部 CA 的 root certificate：

1# Debian/Ubuntu
2cp root_ca.crt /usr/local/share/ca-certificates/internal-ca.crt
3update-ca-certificates
4
5# RHEL/CentOS
6cp root_ca.crt /etc/pki/ca-trust/source/anchors/internal-ca.crt
7update-ca-trust

Docker daemon 也需要信任內部 CA（否則 docker pull harbor.internal/image 會報 TLS 錯誤）：

1mkdir -p /etc/docker/certs.d/harbor.internal
2cp root_ca.crt /etc/docker/certs.d/harbor.internal/ca.crt
3systemctl restart docker

Ansible playbook 批量推送 root CA 到所有機器，是初始部署的標準做法。

cfssl 作為替代

cfssl（Cloudflare 的 PKI 工具組）比 step-ca 更簡單但沒有 ACME 自動化——每張憑證要手動簽發。適合只有 5-10 個服務、不需要自動續期的小規模環境。

Secret Management：HashiCorp Vault

資料庫密碼、API token、TLS 私鑰這些機密值需要一個集中的安全儲存。斷網環境不能用 AWS Secrets Manager 或 GCP Secret Manager，HashiCorp Vault 是最常見的自建選項。

斷網環境的 Vault 初始化

Vault 的初始化（unsealing）在雲端環境通常用 AWS KMS 或 GCP Cloud KMS 自動 unseal。斷網環境沒有雲端 KMS，退回 Shamir’s Secret Sharing——初始化時產生 N 個 unseal key、啟動時需要 M 個 key 才能解鎖（典型設定：5 個 key、3 個即可 unseal）。

1# 初始化 Vault（5 key shares、3 threshold）
2vault operator init -key-shares=5 -key-threshold=3
3
4# Unseal（需要 3 次、每次用不同的 key）
5vault operator unseal <key-1>
6vault operator unseal <key-2>
7vault operator unseal <key-3>

5 個 unseal key 分別交給不同的人保管。任何單一個人都無法獨自解鎖 Vault——這是刻意的安全設計。Vault 重啟後需要重新 unseal，所以 unseal key 的保管和取用流程要事先演練。

機器身分認證

服務從 Vault 讀取 secret 時需要認證自己的身分。雲端環境用 IAM role，斷網環境用 AppRole——每個服務拿到一組 role_id + secret_id、用它們換取短期 token。

 1# 建立 AppRole
 2vault auth enable approle
 3vault write auth/approle/role/gitlab \
 4  token_ttl=1h \
 5  token_max_ttl=4h \
 6  policies=gitlab-secrets
 7
 8# 服務端取得 token
 9vault write auth/approle/login \
10  role_id="$ROLE_ID" \
11  secret_id="$SECRET_ID"

secret_id 本身也是 secret——初次部署時由 Vault admin 手動提供給服務、或透過 Ansible 的 encrypted variable 推送。

儲存後端

Vault 需要一個持久化的儲存後端。雲端用 DynamoDB 或 Consul，斷網環境用：

部署順序的相互依賴

四個服務之間有依賴鏈：

1DNS → NTP → CA → Vault
2 ↑_________________↓（Vault 的 FQDN 要 DNS 解析）

DNS 先啟動（其他服務靠它解析 hostname）→ NTP 跟著（CA 簽發憑證時需要準確的時間、否則 notBefore/notAfter 判斷會出問題）→ CA 啟動（Vault 的 HTTPS 需要 TLS 憑證）→ Vault 最後（依賴 DNS 和 TLS）。

DNS 跟 CA 之間有一個循環依賴：CA 簽發憑證時需要 DNS 解析（ACME challenge 或 CSR 裡的 SAN），但 DNS server 本身要不要 TLS？解法是 DNS 第一次啟動時用明文（不走 HTTPS），CA 啟動後回頭替 DNS 簽一張憑證、再切到 DNS-over-TLS。多數內網環境 DNS 維持明文即可——DNS 查詢在內網不加密是常見做法，風險可控。

時程與維護

四個服務合計約 1.5-2 個工作天完成初始部署。部署完成後的日常維護負擔集中在 Vault（unseal key 管理和 policy 維護）和 DNS zone 更新。CA 的憑證續期如果用 ACME 自動化就接近零維護。

向管理層溝通時的框架：「這四個服務是所有其他服務的地基——沒有它們，其他服務要麼找不到彼此（DNS）、時間對不上（NTP）、通訊不加密（CA）、密碼寫在設定檔裡（Vault）。部署一次、之後幾乎自動運作。」

跨分類引用

• → 斷網環境的通用原則：content ferry 和離線套件管理的通用操作模式
• → 斷網環境的 IaC：Vault 作為 Terraform 的 secret backend
• → 斷網環境的容器與映像管理：Harbor 依賴 DNS 和 TLS、映像拉取需要信任內部 CA
• → 模組二：身分與憑證地基：Vault 的角色跟雲端的 Secrets Manager 對應
• → 模組八：治理好習慣：Secret 不進 code 的原則在斷網環境用 Vault 落地

威脅模型的轉變

連網環境的安全投資集中在邊界防禦：防火牆規則、DDoS 防護、入侵偵測、漏洞修補的速度。斷網環境的邊界是物理的——網路線沒有接上去，防火牆規則不是問題。威脅從「外面的人怎麼進來」變成「裡面的人怎麼把東西帶出去、或把有害的東西帶進來」。

斷網環境的安全投資因此集中在三個面向：控制誰能碰什麼（存取控制）、記錄誰碰了什麼（稽核日誌）、審查什麼東西跨越邊界（傳輸審查）。

實體安全是 infra 的責任

連網環境的實體安全通常歸 facility team——機房門禁、監視器、電力冗餘。infra 團隊負責的是邏輯層的安全（IAM、security group、加密）。斷網環境裡這條分界線消失了：「誰能帶 USB 進機房」直接等於「誰能把任意程式碼注入生產環境」，這是 infra 的安全邊界，不是 facility 的。

需要 infra 團隊參與制定的實體安全政策：

可移除媒體管控：哪些人被授權攜帶 USB / 外接硬碟進入安全區域。媒體是否需要預先登記和加密。進入前是否要在掃描站過掃。政策的嚴格度依環境敏感度而定——最嚴格的環境禁止所有個人裝置、只使用登記在冊的專用搬運媒體。

機房存取控制：門禁卡 / 生物辨識的日誌要進入 infra 的稽核系統。每一次實體進出都要有記錄——誰、什麼時候、待了多久。伺服器機櫃如果有獨立的鎖，鎖的鑰匙管理也歸 infra。

Console 存取：能直接操作伺服器 console（KVM、IPMI、iLO）的人等於擁有最高權限——可以繞過所有 OS 層的認證。console 存取要限制到最小人數，每次使用要記錄。

螢幕與攝影裝置：敏感環境可能限制在安全區域內使用手機（防止拍攝螢幕上的資料）。這個政策的執行通常是 facility 負責，但政策的制定依據（什麼資料在螢幕上算敏感）是 infra 定義的。

身分與認證（沒有雲端 IAM）

連網環境用 OIDC / SSO / 雲端 IAM 管理身分。斷網環境沒有這些——需要自建身分基礎設施。

集中身分管理：FreeIPA（整合 LDAP + Kerberos + DNS + CA）或 OpenLDAP 作為統一的使用者目錄。所有內部服務（GitLab、Nexus、Harbor、Vault、Grafana）都配置 LDAP 認證，避免每個服務各自管一套使用者帳號。FreeIPA 的優勢是把 LDAP、Kerberos、DNS 和 CA 整合在一個管理介面——在資源有限的斷網環境裡減少維運面。

1# FreeIPA 安裝（CentOS/Rocky）
2sudo yum install -y ipa-server ipa-server-dns
3sudo ipa-server-install --setup-dns --no-forwarders

MFA（沒有網路的情況下）：TOTP（如 Google Authenticator）完全在本地運作、不需要網路連線。硬體 token（YubiKey）支援 FIDO2 / PIV / TOTP，在高安全環境是標準做法。智慧卡（CAC / PIV card）在政府和軍事環境最常見。

服務帳號：機器對機器的認證用 Vault 的 AppRole（role_id + secret_id 換取短期 token）或本地 SSL client certificate。不使用長期密碼或寫死的 token。

稽核日誌（沒有 CloudTrail）

連網環境用 CloudTrail / GCP Audit Log 自動記錄所有 API 操作。斷網環境要自建整條稽核鏈：收集 → 傳輸 → 儲存 → 查詢 → 告警。

OS 層級：Linux auditd 記錄 kernel 層的操作——誰執行了什麼指令、誰存取了什麼檔案、誰修改了什麼系統設定。規則用 auditctl 或 /etc/audit/rules.d/ 設定。

1# 監控所有 sudo 操作
2-a always,exit -F arch=b64 -S execve -F euid=0 -k root-commands
3# 監控 /etc/ 目錄的修改
4-w /etc/ -p wa -k etc-changes

服務層級：每個自建服務都有自己的 audit log——GitLab 的 audit events、Vault 的 audit device（可設成 file 或 syslog）、Harbor 的 activity log。這些日誌要匯聚到中央 log server。

集中收集：rsyslog 或 syslog-ng 把各主機的 audit log 轉送到一台專用的 log server。log server 的儲存用 append-only 或 write-once 媒體（防止日誌被竄改）。

日誌完整性：定期對日誌檔做 hash（sha256sum）並把 hash 存到獨立的位置。如果日誌內容被修改，hash 不匹配會被發現。在最高安全等級的環境裡，日誌會同時寫到光碟或 WORM（Write Once Read Many）儲存。

審閱與告警：日誌收集了但沒人看等於沒有。定義哪些事件觸發主動通知（root 登入、非工作時段的操作、大量檔案存取）、哪些事件定期審閱（每週掃描異常模式）。

更新的延遲窗口

連網環境的 CVE 修補可以在小時到天的層級完成——apt update && apt upgrade。斷網環境的修補從「得知漏洞」到「修補上線」之間有結構性的延遲。

典型的延遲鏈：外部公告 CVE → 安全團隊評估影響（1-2 天）→ 在外部環境下載修補（同日）→ 掃描修補本身的安全性（1 天）→ 審批跨邊界傳輸（1-3 天）→ 在斷網測試環境驗證（1-2 天）→ 部署到生產環境（同日）。總延遲 5-10 個工作天。

這個延遲窗口是已知的、可管理的風險。管理方式：

風險接受文件：記錄哪些 CVE 在「已知但尚未修補」的窗口內，每條標註預計修補時間和暫時的補償控制。

補償控制：在修補到位之前降低漏洞的可利用性——禁用受影響的服務功能、收緊網路分段、限制受影響服務的存取權限。

分級修補：不是所有 CVE 都需要緊急處理。Critical（CVSS 9+）走加速通道（目標 3 天內修補）、High（CVSS 7-8.9）走正常通道（目標 10 天）、Medium 以下排進常規更新週期。

跨邊界傳輸的安全審查

每一個跨越隔離邊界的物件都需要審查——套件、映像、設定檔、資料匯出。搬運的操作流程在通用原則篇描述，這裡聚焦安全審查的部分。

掃描站：在邊界設置一台專用的掃描機器，所有入境的媒體先在這裡過掃——防毒掃描、檔案類型驗證、hash 比對（確認下載的套件跟官方發布的 hash 一致）。掃描站本身的病毒定義也需要定期更新（走相同的搬運流程）。

傳輸審批日誌：每次跨邊界傳輸記錄：搬運的內容清單、搬運者、審批者、搬運日期、每個檔案的 hash。這份日誌是稽核的依據——如果內部發現惡意軟體，可以回溯「它是什麼時候、由誰搬進來的」。

Data diode（單向網路裝置）：在最高安全等級的環境裡，跨邊界的網路連線用 data diode——物理上只允許資料往一個方向流動（外部→內部，或反過來）。這比軟體防火牆更難繞過，因為它是硬體限制。data diode 的限制是不支援雙向協定（如 TCP handshake），需要用 UDP-based 的傳輸工具。

主機層入侵偵測

斷網環境的網路流量監控（NIDS）效果有限——內部網路通常扁平、流量加密後難以檢查。主機層入侵偵測（HIDS）是更適合斷網環境的選擇：在每台主機上監控檔案完整性、程序行為、登入模式，而非在網路層攔截。OSSEC 和 Wazuh（OSSEC 的積極維護分支）是開源的 HIDS 方案，agent 裝在每台主機、manager 集中收集告警，不需要連外。

時程與管理層溝通

斷網環境的安全管控初始建置時程：FreeIPA 部署 + 跟所有內部服務（GitLab、Nexus、Harbor、Vault）的 LDAP 整合約需 2-3 天。auditd 規則設定 + syslog 聚合到中央 log server 約需 1 天。掃描站建置（防毒 + hash 驗證 + 傳輸日誌）約需半天。HIDS 部署（Wazuh manager + 各主機 agent）約需 1-2 天。整體安全管控從零到運作約需 5-7 個工作天。

持續維護的主要工作是病毒定義更新搬運（跟隨套件更新週期）、稽核日誌的定期審閱（每週）、以及 CVE 修補的分級處理（依 CVSS 嚴重度排程）。

跨分類引用

• → 模組二：身分與憑證地基：連網環境的 IAM 設計，跟本篇的離線身分方案互補
• → 斷網環境的通用原則：content ferry 模式的操作流程
• → 斷網環境的基礎服務：CA 和 Vault 是本篇認證和機密管理的技術基礎
• → backend 模組七：資安與資料保護：應用層的安全措施