先把界線講清楚，信任才有意義。

01 · 準備度一覽

三種狀態，分開講。

02 · 身分與授權

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

• 只有設定好正式金鑰時，Clerk 才會驗證使用者和目前的組織。
• 要開啟一次應用程式工作階段，必須有啟用中的工作區，而且資料庫裡要有這個人的成員紀錄，一筆不差。
• 權限以資料庫裡的角色為準：擁有者、管理員、設計師、營運人員、檢視者，各有各的權限。
• 一般授權完全不看服務商那邊的組織角色；只有「第一位擁有者」的開通流程是個很窄的例外。
• Studio 的頁面和 API 預設都要通過身分驗證；唯一的計費例外，是 Stripe 帶簽章的那一條 webhook POST。
• 本機開發用的略過機制，必須同時處於開發模式、明確打開旗標，而且主機名稱指向本機，或以 .localhost 結尾。

團隊邀請、服務商與資料庫之間的成員同步、改角色與移除的自動化、撤銷權限，還有稽核事件，我們都還不敢說已經做到可上線的程度。

03 · 租戶資料的界線

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

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

程式碼庫裡有角色與資料列層級政策的完整說明，但正式環境的資料庫角色和遷移狀態，仍必須在選定的 Postgres 服務上逐項核對過，才能上線。

04 · 請求與檔案安全

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

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

05 · 上線發布安全

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

按下上線，系統會把這次請求綁在一個已審閱、不可竄改的版本上，再依你放的元件、它們需要的模組，以及相關的交付替換，算出這個專案能不能發布。Naratake 專案本身是完整的應用程式，後面接著資料庫；只是目前雲端上線先支援不需要資料庫的店面網站，因為託管資料庫服務還沒接上。需要資料庫的專案，會在開始建置、產生產物或動到任何服務商之前就被擋下來。

1. 01
   凍結

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

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

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

3. 03
   驗證

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

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

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

雲端上線目前還沒涵蓋需要資料庫在跑的模組——訂單、收款、訂位、預約、客戶資料，以及其他營運面的功能。這是目前這條交付路徑的限制，不是 Naratake 專案只能做到這樣。自訂網域在這頁同樣不做任何保證。

06 · 金流的界線

金流由伺服器決定；設定不齊，就什麼都不做。

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

服務商的客戶、結帳與訂閱代號，都走一個權限很窄的專用計費角色；一般工作區的資料庫帳號不得存取全域的計費紀錄表。信用卡號一律在 Stripe 自己的頁面上輸入，不會經過 Naratake 的表單。

07 · 我們沒有宣稱的事

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

正式環境一定要走 HTTPS，但傳輸與儲存的保護，最終還是取決於你選的服務商與設定。Naratake 不會把這件事包裝成一套通過獨立認證的加密方案。

08 · 客戶要顧的部分

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

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

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

09 · 回報安全問題

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

寄一封簡短的信，說明受影響的 Naratake 網址或畫面、影響範圍、可以重現的步驟，以及一個安全的概念驗證。請不要存取其他客戶的資料、影響服務運作、把內容帶走、做阻斷服務測試，也不要在信裡附上有效的金鑰或敏感個資。我們目前沒有公開的漏洞獎金計畫，也沒有回應時間的承諾。