工作區就是那條界線，而錢從來不經過我們。

01 · 準備度一覽

三種狀態，分開講。

02 · 身分與授權

在哪裡登入，不決定你在 Naratake 裡有什麼權限。

• Clerk 負責驗證使用者與目前的組織，而正式環境的執行個體帶著那道驗證需要的身分金鑰。
• 要開啟一次應用程式工作階段，必須有啟用中的工作區，而且資料庫裡要有這個人的成員紀錄，一筆不差。
• 權限以資料庫裡的角色為準：擁有者、管理員、設計師、營運人員、檢視者，各有各的權限。
• 一般授權完全不看服務商那邊的組織角色；只有「第一位擁有者」的開通流程是個很窄的例外。
• Studio 的頁面和 API 預設都要通過身分驗證。具名的例外有兩個：Stripe 帶簽章的那一條 webhook POST，以及 /api/health/ready 這個就緒端點——它是刻意公開的，回報平台此刻服不服務得了客戶，不帶任何顧客資料或憑證，而且有一支巡檢每十五分鐘打它一次。你可以自己去開。
• 本機開發用的略過機制，必須同時處於開發模式、明確打開旗標，而且主機名稱指向本機，或以 .localhost 結尾。

一個工作區只有一位擁有者，所以團隊邀請、服務商與資料庫之間的成員同步、改角色的自動化與稽核事件，都不在這一頁的範圍裡。

03 · 租戶資料的界線

瀏覽器沒辦法指定要動哪個工作區。

專案與素材的路由，工作區代號一律從伺服器上已驗證的工作階段取得。網址裡只有專案或素材的代號，決定不了要存取哪個租戶。資料庫這一層用的是不能繞過權限的應用程式角色，並且在交易裡先設好工作區範圍，才開始查租戶的資料。

經過審查的遷移，對應用程式角色碰得到的每一張租戶資料表，都啟用並強制資料列層級安全；任何租戶查詢之前，工作區範圍都已經在交易內設好。至於部署上去的資料庫角色有沒有帶著繞過權限，那是要在正式的 Postgres 服務上做的維運核對，不是應用程式能自己證明的事。

04 · 請求與檔案安全

不可信的輸入，一律先撞到上限。

• 任何會改動資料的路由，都要有通過驗證的角色，而且請求必須完全同源。
• 儲存時會檢查版本前提條件與冪等鍵；過期的寫入會被擋下來，不會默默蓋掉比較新的版本。
• 匯入的專案壓縮檔會逐項檢查：路徑是否正規、是不是只有一份專案文件、檔案數、解壓後大小、壓縮比、JSON 複雜度、結構定義有沒有支援，以及專案身分是否相符。
• 雲端圖片有大小上限、讀取時逐段設限，而且只有在宣告的格式與檔頭特徵位元組相符、且屬於支援的點陣格式時，才會收下。
• 存好的專案包或素材要送出前，會先核對伺服器算出的雜湊值。
• 沒設定好資料庫或私有物件儲存時，直接回「服務無法使用」；正式環境不會退回用瀏覽器或記憶體暫存。

05 · 上線發布安全

還不支援的東西，在切成正式版之前就會被擋下來。

上線會把一次請求綁定到一個不可變的、已審核的版本。資格由專案實際用到的元件、它們需要的模組，以及相關的交付替換算出來。Naratake 專案是一個背後有資料庫的完整應用：完整交付會開好那個資料庫與後台，由 Pro 方案販售；純店面交付是同一個網站拿掉寫入面，拿掉了哪些會逐條列在發佈報告裡。一個工作區能請求哪一種，由提交交易內的權益決定，不是由前端決定。

1. 01
   凍結

   把這次請求綁在指定的版本，以及伺服器已驗證過的專案包上。

2. 02
   在正式環境之外建置

   交給背景工作，依照固定的介面產生一份有上限規範的發布產物。

3. 03
   驗證

   在切換正式版指標之前，先確認產物與發布狀態都對。

4. 04
   切成正式版，或退回上一版

   保留發布紀錄，隨時可以選回先前驗證過的版本。

完整交付會為網站開一個自己的資料庫與商家後台，訪客送出的訂單、訂位、預約、顧客資料與名單都存得住。只有方案同時具備商務與預約兩個模組的工作區才拿得到。純店面交付發佈的是同一個網站但不含訪客會寫入的部分，被移除的每個區塊都會列在發佈報告裡。已發佈網站的線上刷卡，用的是商家自己的 Stripe 金鑰：發佈時從工作區的金鑰保險庫讀出，只寫進那一個網站；兩把必須齊全且模式一致，否則網站會以「沒有結帳」發佈，而不是發佈一個壞掉的結帳。那筆錢 Naratake 從不經手，也不抽成——Stripe 自己的刷卡手續費照收，在哪裡都一樣。你已經擁有的自訂網域，兩個方案各掛一個，並為它簽發 HTTPS。

06 · 金流的界線

金流在正式環境已經設定好，而且設定不齊就一律拒絕。

瀏覽器只能挑一個核可過的方案代號。實際對應到 Stripe、產生正規的返回網址、在呼叫服務商之前先寫下一筆持久的冪等紀錄，都由伺服器負責。Stripe 的 webhook 只有一條路由：它讀取有大小上限的原始內容，驗簽章、驗 API 版本，重複或順序顛倒的事件則靠持久紀錄與游標處理。

服務商的客戶、結帳與訂閱代號，都走一個權限很窄的專用計費角色；一般工作區的資料庫帳號碰不到全域的計費紀錄表。正式環境裡，方案目錄與它的 Stripe 價格對應都讀得出來、結帳依目前模式設定完成、webhook 簽章密鑰也在。這三項執行中的服務會逐項檢查，少一項就把自己標成未就緒，因為「卡刷得下去、東西卻開通不了」正是最該擋下來的失敗。另有一支每小時執行的巡檢，重讀那些流程拒絕套用、又會動到錢的 webhook 決定；只要還有沒清掉的，它就會失敗。

07 · 我們的主張到哪裡為止

沒有證據，就不掛信任標章。

正式環境一定走 HTTPS，而傳輸與儲存的保護，建立在我們設定並持續重讀的那些服務商上。我們把這件事當成拿得出來給你看的工程，而不是一套通過獨立認證的加密方案。

08 · 客戶要顧的部分

安全，也是團隊的日常習慣。

• 顧好登入用的帳號；服務商有提供多重驗證，就把它打開。
• 角色給剛好夠用的就好；有人不再需要這個工作區，就把權限收回來。
• 不要把密碼、私鑰、客戶的機密或信用卡號，貼進頁面文字、專案備註、客服信件或公開素材裡。
• 每次上線前，把內容、連結、表單、政策、串接，還有對外公開的營業資訊都看過一遍。
• 在還原流程演練過、恢復時間也公布出來之前，重要的原始內容請自己另外留一份。
• 懷疑帳號、工作區或已上線的網站被入侵，請盡快告訴我們。

資料怎麼處理，請看隱私權聲明；什麼可以做、上線責任歸誰，請看服務條款。

09 · 回報安全問題

請給我們足夠的細節，讓我們能安全重現。

寄一封簡短的信，說明受影響的 Naratake 網址或畫面、影響範圍、可以重現的步驟，以及一個安全的概念驗證。請不要存取其他客戶的資料、影響服務運作、把內容帶走、做阻斷服務測試，也不要在信裡附上有效的金鑰或敏感個資。回報會直接送到寫這段程式的工程師手上。我們沒有公開的漏洞獎金計畫。