資訊安全
最後更新：2026 年 8 月 1 日
這一頁講的是實際做了什麼，不是承諾會做什麼。每一項都對應到程式碼裡真的存在的機制。
1. 租戶隔離在資料層強制
多租戶系統最致命的錯誤是「A 工作區看到 B 工作區的資料」，而且這種錯誤通常不會報錯，只會靜靜地回傳錯的資料。
所以隔離不靠開發者記得加條件，而是靠結構：
- 取得任何資料存取物件的唯一方式是
repos(db, ctx)—— 沒有工作區脈絡就拿不到東西 - CI 有靜態檢查，會擋掉資料存取層以外的業務表查詢，以及沒有帶隔離條件的查詢
- 同一個檢查也會擋下 SQL 樣板裡的關聯子查詢 —— 那個寫法會讓關聯條件靜默退化成恆真或恆假
2. 到場證明：三層證據
保養這一行最大的爭議是「你這個月到底有沒有來」。紙本可以在辦公室補寫，QR 可以拍照帶走在家掃。
- NTAG424 DNA 動態驗證 —— 每次感應產生不同的密文，附帶單調遞增的計數器。密文以 AES-CMAC 驗證，計數器不遞增即視為重放並拒絕。實作對照 RFC 4493 官方測試向量驗證過。
- 位置圍籬比對 —— 座標可以被模擬，所以它不單獨採信，只作為佐證。
- 時戳、照片、業主簽名 —— 證明時間與人。
證據在工單完成的當下封存。事後補資料不會提升證據等級 —— 如果可以事後補到「充分」，那這個等級就一文不值。
3. 個資加密
身分證字號等識別號碼採三段式處理：可查詢的 HMAC 雜湊、可授權解密的 AES-GCM 密文、供肉眼核對的末四碼。明文不落地。
密碼學一律使用平台原生的 WebCrypto，不引入第三方密碼學套件 —— 這類套件的供應鏈風險遠大於它省下的程式碼。
4. 登入
只走 Google 登入，我們不保存密碼，因此不存在密碼外洩。防護包含：
state參數擋 CSRF- PKCE —— 授權碼即使被攔截也換不到 token
- 只接受站內轉址目標，阻擋開放轉址
- 以 Google 的
sub而非 email 比對帳號
5. 金鑰管理
- 所有密鑰經由部署工具寫入金鑰保管服務，不進版控、不進資料庫、不寫在環境變數檔
- NTAG424 主金鑰只存在於保管服務中。我們無法為你取回，輪替會使既有卡片全部失效
- 個資加密金鑰與查詢用的 HMAC 金鑰分開保管
6. 併發正確性
會造成實質損失的是「同一件東西被借給兩個人」。這類問題靠資料庫的原子操作解決，而非應用層的檢查：
- 借出採比較後寫入（
UPDATE … WHERE status='available'），依實際更新筆數判斷成敗 - 單號採唯一索引加換號重試
兩者都以並行請求實測驗證過，不是「照理說應該沒問題」。
7. 離線
離線內容包（語音、影片、地圖圖磚）由 Service Worker 快取，斷網時仍可播放與定位。
借還等寫入操作目前仍需要連線。離線寫入佇列尚未提供 —— 我們不把還沒做的東西寫成已經有的功能。
會這樣排順序是因為離線寫入與「擋借閘門」本質衝突：閘門要檢查的是即時狀態（是否在庫、校驗是否過期），而離線裝置上只有過期的快照。做不好的結果是校驗過期的器材在離線時被借出，回線才發現 —— 那不是同步衝突，那是合規破口。所以要做就要連同分級與衝突裁決一起做。
8. 漏洞回報
發現安全問題請寄至 perhapxin@perhapxin.com，標題註明「安全回報」。
我們會在三個工作日內回覆。在我們修復並通知你之前，請勿公開揭露。我們不會對善意研究者採取法律行動 —— 前提是不存取他人資料、不破壞服務、不做超出驗證所需的操作。
需要進行滲透測試請先來信約定範圍與時間。