理論階段告一段落，今天開始動手
前五天，我分別用 Threat Model、OWASP、NIST、MITRE ATLAS 四個角度，把這個專案的風險地圖畫得差不多了。今天是整個系列第一個實作里程碑：把腦中設計的東西，變成一個真的能跑的系統。

技術選型：為什麼是 Node.js + Express + Gemini API？
後端框架選 Node.js + Express 的原因很單純，因為這是我目前最熟悉的技術棧，而這個系列的重點是資安攻防的思維與流程，而非比誰用的框架更好。用熟悉的工具能讓我把心力留給真正重要的地方——攻擊測試跟防禦設計，而不是在陌生的語法裡打轉。

LLM 選 Google Gemini API 是因為它有提供免費額度，對一個學生的個人專案來說不用擔心測試量太大而產生費用問題，同時它的 API 呼叫方式跟業界主流做法一致，學到的東西是可以遷移的。

我搭的系統長什麼樣

使用者(Postman / Thunder Client 測試工具)
        ↓
POST 請求到 /chat 這個路徑
        ↓
Express 伺服器接收請求
        ↓
呼叫 Gemini API，並帶入我設定的 System Prompt
        ↓
Gemini 生成回應
        ↓
伺服器把回應包成 JSON，回傳給使用者

核心的 System Prompt 我設定成：
你是一個醫療諮詢輔助機器人，只能回答一般健康衛教知識，不能做診斷。

這句話看起來很單純，但它就是我整個系列裡第一道、也是目前唯一一道防線。之後 Day 8 開始的所有攻擊測試，本質上都是在挑戰：「這句話真的能守住這個系統的角色邊界嗎？」

建置過程中，我學到的兩個資安細節
第一個是關於金鑰管理。API 金鑰是一組專屬於我的密碼，只要外流，任何人都可以冒用它去呼叫 Gemini消耗我的額度。所以我用了 .env 這個檔案單獨存放金鑰，並且在 .gitignore 裡把它排除，確保之後上傳到 GitHub 時金鑰不會被公開。

這其實就是資安裡機密資訊管理最基本、但也最容易被忽略的一環——我自己在測試過程中，就曾經不小心把畫面截圖出去、剛好露出了完整金鑰給了AI，只好當下立刻把那把金鑰刪除、重新申請一把新的。這個小插曲讓我更有感觸：資料外洩不一定是被攻擊者攻破系統，很多時候是操作者自己一個不小心。

第二個是版本控制的過期時間設計。申請 API 金鑰時，系統要求我設定一個到期日而不是預設永久有效。我特地把有效期設得比整個鐵人賽賽期還長一些，確保比賽中不會因為金鑰過期而斷線，但也並未設成永不過期——因為金鑰的生命週期本身，就是資安治理的一部分，不該無限期存在。

目前的系統邊界
老實說現在這個 Chatbot 非常陽春，它只做一件事：接收文字、回傳文字，沒有任何防禦機制、沒有存取控制、沒有紀錄功能。但這正是刻意的——我需要先有一個「完全沒有防護」的版本，才能在接下來的 Red Team 階段準確測出在原始狀態下，這個系統到底有多脆弱。這個版本，就是我全系列 Before / After 對照的起點。

明天預告
Day 7 要做 Baseline 測試，設計一套完整的測試題組，量出這個系統在還沒有任何防禦的狀態下實際的 Attack Success Rate 是多少，建立一份完整的基準報告。

本系列所有病患資料皆為人工生成之虛構資料，不涉及任何真實病患。GitHub Repo:medical-ai-security-lab