# 剛入行工程師一定要建立的幾個安全觀念 很多剛開始學寫程式的同學，會把重心放在框架、語法、演算法上，但進入職場後，你會發現「保護資料」其實也是工程師非常重要的責任。 有些看似不起眼的小習慣，如果沒有建立好，可能會造成系統風險，甚至導致客戶資料外洩。 以下是幾個建議盡早養成的觀念。 --- ## 1. 不要把密鑰放進 Repository API Key、資料庫帳號密碼、Redis 連線字串、JWT Secret 等機密資訊，都不應該直接寫死（Hard Code）在程式碼中。 建議透過： * `.env` * 環境變數（Environment Variables） * Secret Manager 等方式管理敏感資訊。 此外，也要記得將 `.env` 加入 `.gitignore`： ```gitignore .env .env.local .env.production ``` 避免不小心被加入 Git 版本控制。 但要特別注意： `.gitignore` 只能阻止尚未被 Git 追蹤的檔案被加入版本控制。 如果密鑰曾經被 Commit 過，即使後來刪除檔案或加入 `.gitignore`，敏感資訊仍然可能存在於 Git 的歷史紀錄中。 曾經有不少案例是開發者不小心把包含金鑰的程式碼推上 GitHub，之後又將 Repository 設成 Public，結果被自動化掃描工具發現，導致雲端資源遭到濫用或資料外洩。 如果真的不小心將密鑰推上遠端，也不要只是把檔案刪掉就結束。 建議立即執行以下處理： 1. 重新產生（Rotate）新的密鑰 2. 廢止舊密鑰 3. 清理 Git 歷史紀錄 4. 檢查是否已有異常存取紀錄 因為你無法確定舊密鑰是否已經被其他人取得。 與其事後補救，不如一開始就避免把機密資訊放進版本控制系統。 --- ## 2. 與 AI 協作時，也不要直接提供密鑰 現在許多工程師都會使用 AI 協助開發，這是很好的生產力工具。 但有一件事要特別注意： **不要把真實的 API Key、資料庫密碼或客戶資料直接貼給 AI。** 如果想請 AI 幫忙撰寫設定檔，可以改成： ### ❌ 錯誤示範 ```env OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxx DB_PASSWORD=my_real_password ``` ### ✅ 建議方式 ```env OPENAI_API_KEY=YOUR_API_KEY DB_PASSWORD=YOUR_PASSWORD ``` 讓 AI 協助你建立設定結構即可，實際的機密資訊請自行填入。 降低敏感資訊外流的風險，永遠比事後補救來得重要。 --- ## 3. 敏感資料不要明文存放 資料庫中的某些資訊，即使是內部系統，也不應該以明文形式儲存。 例如： * 使用者密碼 * 身分證字號 * 電話號碼 * 銀行帳戶資訊 * 信用卡相關資料 其中密碼更應該使用單向雜湊（Hash）處理，而不是可逆的加密方式。 如果資料庫不幸遭到入侵，適當的保護措施至少能大幅降低資料被直接利用的風險。 --- ## 4. Log 也可能成為資安漏洞 很多新手會把所有資訊都寫進 Log，方便除錯。 例如： ```text Login Success Token: eyJhbGciOi... Phone: 0912345678 ``` 這種做法其實存在風險。 因為： * Log 可能被多人存取 * Log 可能被上傳到第三方平台 * Log 保存時間通常比想像中更久 建議對敏感資訊進行遮罩（Masking）： ```text Token: ************ Phone: 0912****78 ``` 保留必要資訊即可，不需要完整暴露所有內容。 --- ## 5. 不要只讓程式能運作，也要思考資料是否安全 許多初學者在開發時，目標通常是： > 功能有跑起來就好。 但在實務工作中，更重要的是： > 功能能運作，而且資料是安全的。 當系統開始有真實使用者、真實客戶，以及真實商業資料時，工程師的責任就不只是寫功能，而是保護這些資料不被誤用或外洩。 技術能力決定你能做出什麼產品，而安全意識則決定你的產品能走多遠。 --- ## 結語 剛學程式的時候，很容易把注意力全部放在框架、語法和新技術上。 但很多資安問題並不是來自高深的攻擊手法，而是來自一些看似微不足道的習慣： * 把密鑰寫進程式碼 * 將敏感資料明文存放 * 在 Log 中記錄完整個資 * 隨手把機密資訊貼給 AI 養成良好的安全習慣，可能不會讓你今天寫程式變快，但它能讓你未來少踩很多坑，也能讓你成為更值得信任的工程師。