Guidant AI 資安檢視總報告 · 安全需求（SR）
對外 HTTPS、驗憑證、內網不對外、mTLS 要真驗
資料在線上走的那一段要加密、要確認對方是誰、不該暴露的服務不該有入口。這一章 7 條：對外入口、對外部服務的憑證驗證、可選加密的整合預設、SSH 主機指紋、內網服務不映射埠、雙向憑證、依設定才存在的對外位址。3 條有掃描實例、4 條是標準做法。
傳輸安全只問三件事：線上有沒有加密、加密時有沒有確認對方真的是對方（只加密不驗對方，等於把密碼鎖進箱子再交給陌生人）、不該被外面連到的服務有沒有被藏好。掃描抓到的實例集中在第二件——有加密選項但寫死不驗、或預設不驗，攻擊者站在路上假扮對方就收走帳密。其他幾條是依連線特性補的標準做法：明文預設、SSH 不驗指紋、內網服務對外開埠，掃描範圍（程式碼）看不到部署設定，所以沒有實例，但不代表沒問題。
| # | 要求 | 來源 |
|---|---|---|
| SR-03.1 | 對外入口只走 HTTPS | 標準做法 |
| SR-03.2 | 對外部服務的加密連線必須驗憑證與主機名 | 掃描驗證 |
| SR-03.3 | 可選加密的整合預設加密，明文要明示 | 標準做法 |
| SR-03.4 | SSH 連線驗主機指紋 | 標準做法 |
| SR-03.5 | 內網服務不映射到主機埠、不對外 | 標準做法 |
| SR-03.6 | 雙向憑證要嘛真驗、要嘛拿掉 | 掃描驗證 |
| SR-03.7 | 依設定才存在的對外連線位址只收 https | 掃描驗證 |
| 欄位 | 內容 |
|---|---|
| 要求 | 對外入口只走 HTTPS：:80 只能轉向（301）、不得供站；憑證缺失時寧可不啟動、不得退回明文；必須加 HSTS（HTTP Strict Transport Security，讓瀏覽器記住「這個網站永遠走 https」） |
| 為什麼 | 沒有加密通道，上面所有的登入、權杖與資料都是明文，同網段或路上的人直接看得到；沒有 HSTS 時，使用者第一次輸入網址打到 http 的那一下可被攔截降級 |
| 適用連線 | C01 瀏覽器 → 前門（對外入口）。推及：C03（即時連線同走前門）、C04（OAuth 回呼頁同走前門）、C20（代理程式控制面同走前門） |
| 對應威脅 | 無掃描實例（標準做法） |
| 驗證方式 | 對 :80 送任何路徑的 GET，必須回 301 轉到 https 且不帶頁面內容；移除憑證檔後啟動前門，必須啟動失敗而非改聽 http；對 https 回應檢查標頭必須含 Strict-Transport-Security |
| 來源 | 標準做法：C01 D6◇ |
| 欄位 | 內容 |
|---|---|
| 要求 | 對外部服務（Redis、郵件伺服器、LDAP／AD、日誌收集端 SIEM、GitHub／GitLab、OpenVAS）的加密連線，必須驗對方憑證與主機名（CERT_REQUIRED＋主機名比對）。「不驗證」只能是客戶明示選擇的選項，不得是預設；客戶的自簽憑證以「貼上信任憑證（CA）」解決，不得以關掉驗證解決；程式碼中不得出現 verify=False、ssl_verify=False 這類寫法，並由 lint 規則或守衛測試掃描確保不再出現 |
| 為什麼 | 只加密不驗對方時，站在路上的人拿一張自簽憑證假扮對方，就收走帳號密碼——郵件密碼、客戶目錄服務帳密與每位員工的登入密碼、GitHub 通行證、Redis 帳密；對 SIEM 則是整份系統日誌 |
| 適用連線 | C06 api → Redis、C10 api → 郵件伺服器、C11 api → 客戶 LDAP／AD、C12 api → 客戶 SIEM、C15 api → 外部問題單、C23a agent → 弱點掃描工具伺服器。推及：C13（對 AI 服務）、C14（對 Google）、C18（對授權簽發站）、C23（WinRM 接受自簽憑證）——凡本系統作為用戶端連出去的加密連線都適用 |
| 對應威脅 | C06 T1 在容器網路上假扮 Redis ⚪、C10 T2 站在路上假扮郵件伺服器 🟡、C11 T3 站在路上假扮目錄伺服器 🟠、C12 T1 在路上側錄全部日誌 🟡、C15 T1 站在路上假扮 GitHub，收走通行證 🟡、C23a T1 假冒工具伺服器，接走管理員帳密／T2 假冒工具伺服器，回假報告（無掃描實例） |
| 驗證方式 | 對每個外部服務，起一台出示自簽（或主機名不符）憑證的假服務，系統連線必須失敗並回明確的憑證驗證錯誤、不得送出任何帳密；貼上該假服務的 CA 後再連必須成功；全專案 grep verify=False／ssl_verify=False／CERT_NONE 必須無命中（或僅命中明示選項的分支） |
| 來源 | 掃描驗證：C06 D1（實例 M04-6）、C10 D2（實例 M16-3）、C11 D3（實例 M13-2）、C12 D1（實例 M09-3）、C15 D1（實例 M23-4）、C23a D1◇ |
| 欄位 | 內容 |
|---|---|
| 要求 | 可選擇加密與否的整合（LDAP、SIEM 日誌轉送、郵件 SMTP、WinRM、ZAP／SonarQube），預設必須是加密；走明文必須由客戶明示開啟，不得是預設值或升級後的缺省值。設定頁對「不驗憑證」與「明文」兩種選擇必須有明顯風險提示 |
| 為什麼 | 預設明文時，客戶不主動改就是明文：員工的登入密碼、服務帳密、整份系統日誌、郵件內容在同網段封包裡一覽無遺；設定頁沒有提示，客戶根本不知道自己處於這種狀態 |
| 適用連線 | C11 api → LDAP／AD、C10 api → 郵件伺服器、C23 agent → 受檢主機（WinRM）、C23a agent → 工具伺服器（ZAP／SonarQube）。推及：C12（日誌轉送預設 UDP 明文，同型）、C06（REDIS_SSL 預設關） |
| 對應威脅 | C11 T3 站在路上假扮目錄伺服器 🟠（無加密是更壞的版本）、C10 T2 站在路上假扮郵件伺服器 🟡、C23 T2 假冒受檢主機，接走帳密、C23a T1／T2（以上 C23、C23a 無掃描實例） |
| 驗證方式 | 以全新安裝（及從舊版升級後）建立每種整合的預設設定，檢查加密欄位的值必須是加密；對「選明文」或「不驗憑證」的設定頁，畫面上必須出現風險警示文字；對預設設定抓封包，不得看到明文帳密 |
| 來源 | 標準做法：C11 D4◇、C10 D6◇、C23 D4◇、C23a D2◇ |
| 欄位 | 內容 |
|---|---|
| 要求 | 代理程式以 SSH 連受檢主機時，必須驗主機指紋：首次連線記下指紋、之後指紋不符即拒絕連線（與 SSH 用戶端的 known_hosts 同義）；或由客戶在工具設定頁預填指紋。不得每次都自動接受（例如 paramiko 的 AutoAddPolicy） |
| 為什麼 | 不驗指紋時，站在路上或假冒受檢主機的人接走客戶「能 sudo 的維運帳密」，再用它登進真正的主機——對方是誰完全沒驗 |
| 適用連線 | C23 agent → 受檢主機 |
| 對應威脅 | C23 T2 假冒受檢主機，接走帳密（無掃描實例） |
| 驗證方式 | 對一台已記錄指紋的受檢主機，換成另一台不同金鑰的主機（同 IP）後發動連線，必須被拒且不得送出帳密；首次連線後檢查指紋已落設定或登記 |
| 來源 | 標準做法：C23 D3◇ |
| 欄位 | 內容 |
|---|---|
| 要求 | 內網服務（資料庫、Redis、檔案儲存 SeaweedFS、沙箱、agent 端的 S3）不得映射到主機對外埠；容器間只走內部網路（expose 而非 ports）；若必須開埠只綁本機位址（127.0.0.1），金鑰必填、不入版控，綁定位址被改成 0.0.0.0 時要有警告 |
| 為什麼 | 內網服務通常以「在內網所以可信」為前提，帳密也相對簡單；埠一旦對外，同網段的人直接連進去讀整個資料庫、整桶證據或客戶全部主機的弱點地圖 |
| 適用連線 | C05 api → 資料庫、C06 api → Redis、C07 api → 檔案儲存、C22 agent → SeaweedFS。推及：C08（沙箱容器同屬內網服務） |
| 對應威脅 | C07 T6 在容器網路上側錄後端與儲存之間的明文流量 ⚪、C22 T2 金鑰或埠外露，同網段的人直接讀整桶（無掃描實例）；C05、C06 為「這條線的前提」，無對應單一威脅 |
| 驗證方式 | 檢視 compose／部署檔，上述服務不得有映射到 0.0.0.0 的 ports:；以 docker ps／docker inspect 看實際生效的埠映射，產品容器除前門 80/443 與 agent 資料面 8443 外不得發布任何對外埠；把 S3 綁定位址改成 0.0.0.0 時設定頁或安裝程式必須顯示警告 |
| 來源 | 標準做法：C05 D8◇、C06 D2◇、C07 D6◇、C22 D1◇ |
| 欄位 | 內容 |
|---|---|
| 要求 | 雙向憑證（mTLS，連線雙方都出示憑證）必須要嘛真的驗、要嘛拿掉——不得留「出示但不看」的假象：一端出示憑證、另一端不驗，會讓人誤以為有第二層保護。要驗的地方：agent 資料面入站 TLS 層強制客戶端憑證（CERT_REQUIRED），再驗綁定這台機器的短效票（JWT 帶受眾＝機器編號、硬體指紋、效期以秒計、每次現簽）。要拿掉的地方：文件與網路圖明寫「控制面只靠通行證」 |
| 為什麼 | 前門不驗客戶端憑證卻讓 agent 照樣出示，日後有人以為 mTLS 在守而放鬆通行證那層，就出事；資料面入站若不強制，任何人都能冒充雲端打進客戶機房，把代理程式當跳板掃內網、取走掃描報告 |
| 適用連線 | C20 agent → 主系統前門（控制面）、C21 api → agent 資料面 |
| 對應威脅 | C20 T1 冒充代理程式——後端認不出對方是哪台機器 🔴（D7 為其延伸）、C21 T1 冒充雲端打進客戶機房 🔴 |
| 驗證方式 | 資料面：不帶客戶端憑證連 :8443 必須在 TLS 交握階段被拒；帶憑證但無票、或帶別台機器的票、或過期票必須 401／403。控制面：若宣稱有 mTLS，不帶客戶端憑證打前門的 agent 路徑必須被拒；若宣稱沒有，文件中必須明寫且前門設定不得殘留看似驗證的指令 |
| 來源 | 掃描驗證：C20 D7◇、C21 D1（實例 M01-1） |
| 欄位 | 內容 |
|---|---|
| 要求 | 位址由客戶或設定填寫、依設定才存在的對外連線（AI 服務 base_url、License 簽發站位址、規則包網址、webhook），位址只收 https；拒絕內網段與環回位址；host 精確比對，不得用 endswith 等模糊比對；webhook 另限官方網域、固定路徑前綴、不帶帳密、不接受非預設埠；既有 http 設定要有退場（警告→期限→停用）。允許的 scheme 清單只有一份（共用 safe_http_fetch.ALLOWED_SCHEMES），不各處另立 |
| 為什麼 | 位址可被改時：攻擊者把原廠 AI 金鑰、簽發站 API 權杖騙送到自己的伺服器，或把規則包下載路徑上的內容換掉，在客戶內網的代理程式上執行任意程式碼並偽造掃描結果；用 http 還連「破解」都不用 |
| 適用連線 | C13 api → 外部 AI、C18 api → 授權簽發站、C19 api → 規則包網址、C24 agent → 規則包網址、C16 api → 聊天 webhook |
| 對應威脅 | C13 T1 把原廠金鑰騙到自己的伺服器 🟡、C19 T3 網址不加密、沒指紋，代理程式拿到什麼就跑什麼 🟡、C24 T1 在下載路徑上換掉規則包 🟡、C16 T1 拿「測試」按鈕當跳板打內網（無掃描實例）；C18 D5 無單一對應威脅（擋假扮簽發站拿走權杖） |
| 驗證方式 | 對每個可填位址的設定欄位，分別填 http://…、https://127.0.0.1、https://內網 IP、https://official.example.evil.com（以官方網域當後綴）：必須全被拒；填合法 https 位址可存；既有 http 設定在使用時必須寫警告 |
| 來源 | 掃描驗證：C19 D3、C24 D1（實例 M03-5）、C13 D6◇、C18 D5◇、C16 D1◇ |
來源：連線頁的防線（D）；去重對照在 requirements/_drafts/D-to-SR.md。