把業務應用程式放在自家雲端的設計｜權限、資料所在地與個人資料

大家好，我是株式會社TIMEWELL的濱本 隆太。

解約高價的SaaS，改為自己持有業務應用程式。這個系列從判斷基準寫起，接著寫了哪些業務適合自己做、5年總額怎麼試算、解約與移轉怎麼安排。第五篇要處理最後剩下的問題：重新做好的應用程式，要放在哪裡。

先講結論。我的看法是，一旦決定自己持有，放在自家簽約的雲端環境，也就是本文所說的「自家租用戶」，通常比較好運作。因為可以和公司內部的身分管理平台與權限對齊，容易串接既有資料，稽核日誌也能自己保存。不過，換了放置位置，個人資料的整理方式與維運責任也會跟著移動，並不是選了日本區域就能解決。本文寫給資訊部門、資安與個人資料負責人、ISMS的推動窗口，依一手資料寫出好處與負擔兩面。想先從「該不該解約」讀起的話，請從系列的判斷基準篇開始。

另外先說明：本文以日本《個人資料保護法》（日文原名「個人情報保護法」，英文簡稱APPI）為例。在台灣營運的企業，另須依台灣《個人資料保護法》判斷。

多租戶SaaS和自家租用戶，差在哪裡

先整理用語。美國國家標準暨技術研究院（NIST）的SP 800-145是最常被引用的雲端定義，它把「資源共用（resource pooling）」列為雲端的特徵之一，寫到業者的運算資源以「多租戶模式」提供給多個使用者¹。同一份文件對SaaS的定義是：使用者不管理也不控制網路、伺服器、作業系統、儲存，甚至個別應用程式的功能（唯一的例外是有限的個別使用者設定）。換句話說，SaaS的使用者能碰到的，幾乎只有設定畫面。

本文所說的「自家租用戶」，是指在自家簽約的雲端平台（AWS、Microsoft Azure、Google Cloud等）帳號裡，把業務應用程式與資料當成自家資產放置的型態。雲端平台本身是雲端業者的共用設施，但應用程式的管理者、資料的持有者、分配權限的人都是自家。這也和廠商為每個客戶準備專屬環境的「單一租戶型SaaS」不同。即使是專屬環境，只要是廠商在維運，應用程式與資料的鑰匙就還在廠商手上。

提供SaaS的一方有一份設計指引，是AWS Well-Architected的「SaaS Lens」。它把所有租用戶共用基礎架構的型態稱為「集區（pool）」，把依租用戶分開的型態稱為「孤島（silo）」，並列出各自的優缺點²³。集區型的缺點包括：其他租用戶的負載會影響到自己的「吵鬧鄰居（noisy neighbor）」、難以掌握每個租用戶的成本、故障影響範圍較廣（原文寫道，集區型的故障「很可能影響系統中所有租用戶」），以及在法規要求資源嚴格隔離的場合會遇到阻力。孤島型正好相反，容易滿足隔離要求、影響範圍也窄，但成本較高，也較難一次更新所有租用戶。這份文件是寫給做SaaS的公司看的，但從使用者這一側來讀，就能看出自己用的服務拿什麼換來了現在的價格。

面向	多租戶SaaS	廠商維運的專屬環境SaaS	自家租用戶
基礎架構與應用程式的維運者	廠商	廠商	自家（或自家委託的對象）
帳號與權限的管理	每個服務各自的管理後台	每個服務各自的管理後台	可與自家身分管理平台對齊
操作紀錄（稽核日誌）	能匯出的範圍與保存期間由廠商決定	同左	保存位置與期間由自家決定
規格變更的時間點	廠商決定	有較大的協商空間	自家決定
故障的影響範圍	可能和其他公司一起停擺	較容易侷限在自家環境	較容易侷限在自家環境
維運、監控、修補的責任	大部分由廠商負責	大部分由廠商負責	轉到自家
費用的結構	與使用者人數等成正比	通常較貴	雲端使用費加上維運人力

表格下方兩列，就是本文後半要談的負擔。可以把自家租用戶想成：在上面五列得利，在下面兩列付出。

放在自家租用戶，哪些事情會變得好運作

我說「比較好運作」，指的是四件事。

第一，身分與權限可以對齊。用了10個SaaS，就有10個管理後台、10套權限設計。每次到職、調動、離職，都要到各個後台修改帳號，總有某處會漏刪。放在自家租用戶，就能用公司身分管理平台上的同一組群組來切權限。例如AWS的IAM Identity Center說明，可以連接既有的身分識別提供者，並同步目錄中的使用者與群組⁴。調動一旦寫進人事資料，業務應用程式的權限也會照同一條路徑改變。這種集中管理，在ISMS內部稽核說明權限審查時也很有幫助。

第二，容易串接既有資料。報價紀錄、內部FAQ、申請紀錄。這些資料如果在同一個租用戶裡，就不必經過外部API也能串起來。SaaS之間互相串接時，能同步的項目與頻率往往受廠商的API與方案限制，有些資料要升級到較高方案才拿得出來。哪些業務適合自己做，我在系列第二篇寫過；我的感覺是，越是被列為候選的業務，越多是要和其他資料串起來才會產生價值的。

第三，稽核日誌可以自己保存。誰、在什麼時候、對哪筆資料做了什麼。在SaaS裡，這份紀錄能看到多少、保留幾天，是廠商決定的。放在自家租用戶，保存位置和期間都由自家決定。AWS CloudTrail會把使用者、角色與AWS服務的操作記錄為事件，不做任何設定就能查看的事件歷史，是過去90天的管理事件⁵。想保存更久，就要自己設定存放位置。反過來說，什麼都不做，90天後紀錄就看不到了，這正是設計時要先決定的項目之一。

第四，比較不會被廠商的規格變更牽著走。在SaaS裡，畫面改版、功能下架、方案重組、服務條款修改，都是依廠商的時程來。日本民法對定型化契約條款規定，變更符合相對人一般利益時，或依變更的必要性、變更後內容的相當性等情事判斷為合理時，可以不經個別同意而變更內容（第548條之4）⁶。企業用SaaS的條款是否屬於定型化契約條款要個案判斷，但至少應該以「條款是對方可以改的」為前提來讀合約。自家租用戶裡的應用程式，變更的時間點由自家決定。不過雲端平台這一側也會有執行環境停止支援之類的變更，減少的是會牽動你的對象，而不是歸零。

這四件事的根源相同：應用程式與資料，和自家其他系統放在同一個地方。既然要停用SaaS、重新打造，把放置位置也一起設計進去，重新打造的意義才會更大。這就是我這樣判斷的理由。

個人資料算不算委託？關鍵在「誰碰得到」

接著是個人資料的整理。這裡應該是最容易誤解的地方。

先為不熟悉日本法的讀者補充背景。日本個人資料保護法原則上要求，把個人資料提供給第三人之前須取得當事人同意。例外之一是「委託」：把個人資料的處理委託給其他業者時，不需要同意，但委託方必須監督受託者（第25條）。主管機關日本個人資訊保護委員會（PPC）公開了個人資料保護法指引的問答集（Q&A），其中有幾題直接處理雲端服務。

Q7-53指出，使用雲端服務是否構成需當事人同意的提供給第三人，或構成委託，判斷基準不是「儲存的電子資料是否含有個人資料」，而是「提供雲端服務的業者是否被安排會處理個人資料」⁷。它舉的「不處理」的例子是：合約條款載明業者不處理存放在伺服器上的個人資料，而且確實做好存取控制。這種情況不構成提供，因此既不需要當事人同意，也不需要依第25條監督受託者。日本實務上有時稱之為「雲端例外」。

緊接著的Q7-54補了一句提醒：即使不構成提供，使用服務的業者仍須「作為自己應盡的安全管理措施的一環，採取適當的安全管理措施」⁸。監督受託者的義務沒有了，自家該做的事卻原封不動留下來。

那SaaS呢？日本個人資訊保護委員會在2024年3月25日，針對一件判斷雲端服務業者屬於個人資料處理業者（受託者）的案件，發布了提醒公告⁹。那是業者提供的業務系統遭到未經授權存取，許多使用企業的客戶員工個人資料被加密的案件。委員會考量的因素有三個。服務條款規定，業者認為維護或維運上有必要時，可以監控、分析、調查資料。業者持有維護用帳號，處於可以存取客戶個人資料的狀態，且沒有防止處理的技術性存取控制。雙方交換確認書後，業者實際處理了個人資料。公告並要求使用者把雙方同意的安全管理措施，在條款或合約中「盡可能客觀地明確化」，並透過定期報告等方式確認。只要是由廠商維運應用程式，SaaS的結構就容易讓廠商在維護或支援時碰到客戶資料。我把這份公告讀成：主管機關把這件事以行政判斷的形式講清楚了。

接下來是思考自家租用戶時不能跳過的一點。Q7-53的基準不是「放在哪裡」，而是「誰處理個人資料」。既然如此，即使放在自家租用戶，只要負責開發或維護的外部廠商碰得到正式環境的個人資料，和這家廠商的關係就應該整理為委託。問答集並沒有直接寫到這個情境，這是我套用Q7-53的基準與公告的考量因素所做的解讀；但能用維護用帳號看到正式環境資料的外部廠商，和公告案件中的業者處境非常相似。像我們這樣的FDE（Forward Deployed Engineer，進駐客戶現場開發的工程師）負責維護時，也不例外。

架構	外部業者碰得到資料嗎	整理方向（一般論）	留在自家的事
多租戶SaaS	維護或支援時可能碰到	多半構成委託	監督受託者（第25條）、在合約中明確化
自家租用戶，只有公司內部人員維運	雲端平台業者以合約約定不處理，並做好存取控制	可整理為既非提供也非委託（Q7-53）	自家的安全管理措施（Q7-54）
自家租用戶，外部廠商用正式環境資料進行維護	碰得到	以委託處理	監督受託者、記錄存取
自家租用戶，外部廠商只用遮罩過的資料開發，沒有正式環境權限	設計成碰不到	有可能整理為不構成委託	維持權限設計並保留佐證紀錄

2026年的日本修法也和這個整理有關。2026年7月10日通過、7月17日公布的個人資料保護法修正，明文規定受託處理個人資料的業者，不得超出執行受託業務所需的範圍處理個人資料¹⁰¹¹。同時也設計了一套機制：在受託者不自行決定處理方法的情況（例如只是依委託方指示機械式處理），若委託合約對處理方法的全部達成合意，並對委託方掌握處理狀況所需的措施（例如得知外洩時立即通報）達成合意，原則上免除受託者作為處理業者的各項義務。不過，不得超出必要範圍處理的義務與安全管理的義務仍然適用。施行日期為公布後兩年內，細節還在內閣政令與委員會規則中研議。像維護這種需要廠商自行判斷的工作能否適用這項免除，要等規則定案後再確認。

方向倒是很清楚：委託合約裡「處理什麼、用什麼方法處理」「如何掌握狀況」這些內容會越來越重要。如果要讓外部維護廠商進入自家租用戶，現在就把這些寫進合約，等到施行時應該就不必手忙腳亂。

以上是一般論。個別架構是否構成委託，請與貴公司法務或專家確認。

選了日本區域，還是有事情要確認

常聽到「放在日本區域就安心了」的說法。我認為這句話對一半，另一半容易造成誤解。

先說對的一半。在雲端上，可以用國家或地區為單位選擇資料存放位置。NIST的定義也寫到，使用者通常無法控制或得知資源的確切位置，但可能可以在較高的層級指定，例如國家、州或資料中心¹。AWS在日本有東京（4個可用區域）與大阪（3個可用區域）兩個區域¹²。

容易誤解的另一半，出自問答集Q10-25¹³。使用位於外國的業者所提供的雲端服務時，即使業者不處理個人資料，使用的企業仍「因為是在外國處理個人資料，須先掌握該外國的個人資料保護制度等，再採取安全管理措施」。回答接著寫道：「個人資料存放在位於日本國內的伺服器時，也相同。」此外，作為安全管理所採取的措施，還須明示雲端業者所在外國的名稱與伺服器所在外國的名稱，並讓當事人能夠得知在掌握該外國制度後所採取的措施內容。把資料存放在外國伺服器本身，若整理為業者不處理，就不構成提供給位於外國的第三人（第28條），但掌握外國制度的必要依然存在（Q12-3）¹⁴。

所以，即使選了東京區域，只要雲端業者是外國公司，掌握該國制度的工作就不會消失。選擇區域主要改變的，是公開內容中「伺服器所在國」那一欄。並不會因為放在日本，就不需要說明。

導入生成式AI時，還多一層。因為資料的存放位置，和AI處理推論的位置是兩回事。例如AWS的Bedrock有把推論請求分派到多個區域的功能，可以選擇限定在美國、歐盟等特定地理範圍的設定檔，或分派到全球商用區域的全球設定檔¹⁵。依AWS的說明，有資料所在地要求時應選擇地理範圍；全球設定檔沒有地理限制，但價格約便宜10%。資料存在東京，推論在哪裡處理，則取決於設定。

那該怎麼設計？我建議不要一開始就把區域寫死，而是設計成可以依需求選擇。合約或產業規範要求在日本國內處理的資料，選擇在國內範圍處理的設定；其他資料，則選擇準確度與費用相稱的模型和處理位置。選了哪一種要記錄下來，並和對當事人的公開事項、公司內部的清冊保持一致。我們的FDE也不一律限定處理區域，而是用這個思路來規劃。

比區域更該先確認的，是輸入的資料會不會被拿去訓練模型。我們只選擇能透過服務條款、合約或設定其中之一，確認客戶資料不會被用於訓練的服務與模型，並記錄所依據的內容。要確認的，是雲端業者或模型提供者自己的說明。例如AWS在Bedrock的FAQ中明確寫到，AWS與第三方模型提供者都不會把Bedrock的輸入與輸出用於模型訓練¹⁶。把這類說明當成選用依據留在清冊裡，稽核時的說明就能簡短許多。

維運責任轉到自家，要在設計時先決定

前面談了比較多好處，接下來談要付出的部分。

雲端的責任分工，AWS的「責任共擔模型」是很好懂的整理¹⁷。AWS負責「雲端本身的安全」，也就是保護硬體、軟體、網路與設施；使用者負責「雲端中的安全」。使用者的責任範圍，取決於選用了哪些服務。選擇虛擬伺服器（Amazon EC2）這類IaaS，客體作業系統的更新與安全修補程式、上面的應用程式軟體，以及防火牆（安全群組）的設定，全都由使用者負責。比較安全的想法是：過去SaaS廠商承擔的工作，在移進自家租用戶的那一刻，就變成自家的工作。

工作	使用SaaS時	自家租用戶時	減輕負擔的做法
作業系統與中介軟體的修補	廠商	自家	選用受管服務或無伺服器架構，從源頭減少要修補的對象
監控與故障處理	廠商	自家	一開始就決定監控項目與聯絡順序，並講清楚夜間怎麼處理
備份與還原	廠商（範圍依條款而定）	自家	不只做備份，把還原演練排進年度行事曆
帳號與權限盤點	每個服務各自進行	透過自家身分管理平台一次進行	盤點週期與ISMS內部稽核對齊
稽核日誌保存	廠商能匯出的範圍	自家	決定存放位置、保存期間與可查閱的人
應用程式碼的弱點	廠商	自家	把程式碼審查與自動檢測放進開發流程
資料刪除	解約時由廠商刪除	自家	把保存期間與刪除程序寫進設計文件

負責ISMS的讀者，也請重新對照一下控制措施。ISO/IEC 27001:2022（日本國家標準為JIS Q 27001:2023）新增了11項控制措施，其中包括「5.23 使用雲端服務的資訊安全」「8.10 資訊刪除」「8.16 監控活動」「8.28 安全程式設計」¹⁸。使用SaaS的時候，5.23的重點是「怎麼選SaaS、怎麼用SaaS」。移到自家租用戶之後，5.23的對象就變成雲端平台的使用，再加上8.16的監控與8.28的程式設計成為自家的工作。適用性聲明（SoA）可能也需要重新檢視。

在用生成式AI寫程式的今天，8.28的份量變重了。史丹佛大學研究人員在2023年ACM CCS發表的使用者研究指出，能使用AI助理的參與者，寫出的程式碼比不能使用的參與者更不安全，而且更容易認為自己的程式碼是安全的¹⁹。這是當時模型的結果，不一定能直接套用到現在的工具。即使如此，我認為不該以速度為理由，省略由人審查AI所寫程式碼的步驟。

8.10的刪除，在移轉時也會出現。確認已解約SaaS裡殘留的資料確實刪除，以及在新應用程式裡刪除超過保存期間資料的機制，是兩件分開的工作。前者的安排寫在解約與移轉實務篇，連維運人力都算進去的費用比較方法寫在5年總額試算篇。最想避免的失誤，是沒估算自家租用戶的維運成本，就判斷「比SaaS便宜」。

我們的FDE能做什麼

以下說明我們的FDE如何承接上述工作。FDE是進駐客戶現場、一邊觀察業務一邊做出可運作之物的工程師。我們認為，SaaS的解約與內製化，是可以用FDE實際執行的工作。服務全貌整理在FDE服務頁面。

第一步是在決定放置位置之前先盤點。要解約哪些SaaS、改為自己持有；該業務的資料從哪裡來、往哪裡去；個人資料包含在哪裡。先把這些寫出來，再進入設計。

接著是自家租用戶的設計。帳號怎麼切分、如何與公司身分管理平台連接、權限的型、稽核日誌的存放位置與期間、備份與還原演練，都在這一步決定。區域設計成可依需求選擇，並把需要在日本國內處理的資料與不需要的資料分開記錄。導入生成式AI時，如前所述，只選擇能確認不會被用於訓練的服務與模型，並留下依據。

開發時使用遮罩掉個人資料等內容的資料。要寫入正式業務系統的功能，在權限、執行前模擬、重要判斷由人確認、稽核紀錄這四項條件齊備之前，不會上線。若我們需要承擔會碰到正式環境個人資料的維護工作，就以構成委託為前提，把處理範圍、存取方式與紀錄、外洩時的通報寫進合約。我們已取得ISO/IEC 27001驗證（驗證範圍：運用AI技術之SaaS產品的企劃、開發與提供）。

期間以45到90天為區隔。結束條件是貴公司的團隊能獨立維運。修補程序、權限盤點、還原演練，都要做到貴公司的負責人能自己執行為止，這些都包含在期間內。哪些由自家做、哪些交給外部的界線，我也在AI內製化界線篇寫過。

與委外開發的差異

委外開發也可以在自家租用戶裡做應用程式。差別在工時的性質、學習的去向，以及結束的方式。

委外開發的工時是營收。維護越久營收越多，所以讓維運留在廠商手上的設計，對廠商來說是很自然的選擇。結果，原本放在自家租用戶的應用程式，實際上變成只有外部維護廠商碰得了，對受託者的監督也沒完沒了。這只是把對SaaS的依賴，換成對另一個對象的依賴而已。

我們的FDE把工時當成投資。目標是每位客戶的現場工時逐漸減少，貴公司團隊能自行運作時就結束合約。其他公司也用得到的共通機制回流到我們的產品，讓下一位客戶從第一天就能用；貴公司專屬的設定與業務資料，則歸貴公司所有。放在自家租用戶，和這種結束方式很合得來。應用程式與資料從一開始就在貴公司的環境裡，我們離開時沒有任何東西需要帶走。FDE與其他支援方式的差異，我在FDE與AI陪跑支援比較篇有詳細說明。

我們的實踐與限制

坦白說，自家租用戶不是每家公司都適合的放置位置。

沒有人負責維運的公司，我們很難推薦。上面表格列出的工作，上線後每個月都會發生。若公司內部沒有能負責維運的人，也決定不了要交給誰，繼續用SaaS，或改用廠商維運的專屬環境，可能更合適。這個判斷，我們會在第一次諮詢時直接說明。

若選擇由我們持續維護的架構，委託關係也會持續，監督的工作仍留在貴公司。我們以自行運作為結束條件，但像夜間故障處理這類公司內部難以承擔的工作，也可能留下來。這種情況，請和我們另外討論限定範圍的維護合約；那份合約同樣會明確寫出處理範圍。

我們不一律限定處理區域。必須在日本國內處理的專案，會在個別合約中約定，並反映在費用上。為了避免被理解成「委託我們就自動在日本國內處理」，這一點會在一開始確認。

我們不是律師事務所。是否構成委託、外國制度要掌握到什麼程度，最終判斷交給貴公司的法務或專家。我們能準備的是判斷所需的架構圖、存取路徑與紀錄。ISO/IEC 27001的驗證範圍也如上所述，我們不會用讓人以為驗證及於在貴公司租用戶內個別作業的方式來描述。

最後是產能。我們是小公司，能同時進駐的現場數量有限。

總結

決定自己持有的業務應用程式，放在自家租用戶通常比較好運作，這是我的看法。因為可以和公司的身分管理平台與權限對齊、串接既有資料、自己保存稽核日誌，並由自家決定規格變更的時間點。

相對地，要承接兩件事。一是個人資料的整理。是否構成委託，取決的不是放在哪裡，而是「誰處理個人資料」。開發或維護的外部廠商碰得到正式環境資料時，以委託處理；若要設計成碰不到，就用權限設計與佐證紀錄來支撐。即使選了日本區域，只要是外國業者的雲端，掌握外國制度的工作仍然存在。二是維運責任，修補、監控、備份、刪除都直接成為自家的工作。

如果週一只做一件事，請拿出正在考慮解約的SaaS，從合約與條款確認「廠商那一側是誰、用哪個帳號、碰得到自家的資料」。答案不清楚的話，這本身就是評估自家租用戶的理由之一。

想用FDE推動自家租用戶的設計與移轉，歡迎參考FDE服務頁面，或透過FDE個別諮詢和我們聊聊。想從頭閱讀本系列，請從判斷基準篇開始。

Footnotes

1. NIST Special Publication 800-145, The NIST Definition of Cloud Computing（NIST，2011年9月）。resource pooling、SaaS、private cloud的定義依該文件（筆者譯） ↩ ↩²

2. Pool isolation（AWS Well-Architected, SaaS Lens）。集區型的優缺點（noisy neighbor、tenant cost tracking、increased scope of impact、compliance pushback）依該頁（筆者譯） ↩

3. Silo isolation（AWS Well-Architected, SaaS Lens） ↩

4. What is IAM Identity Center?（AWS IAM Identity Center User Guide） ↩

5. What Is AWS CloudTrail?（AWS CloudTrail User Guide）。事件歷史為過去90天的管理事件，依該頁 ↩

6. 日本民法（明治二十九年法律第八十九號）第548條之4（定型化契約條款的變更）。e-Gov法令檢索，日文 ↩

7. 個人資料保護法指引問答集 Q7-53（日本個人資訊保護委員會）。日文，引文為筆者譯 ↩

8. 同問答集 Q7-54（日本個人資訊保護委員會）。日文 ↩

9. 雲端服務業者屬於個人資料保護法上的個人資料處理業者時的注意事項（提醒公告）（日本個人資訊保護委員會，2024年3月25日）。日文 ↩

10. 關於個人資料保護法等部分修正法律（日本個人資訊保護委員會事務局，2026年7月）。對受託者規範的調整在第12頁，修正後條文為第30條之3。相關資料一覽見2026年修正個人資料保護法頁面。日文 ↩

11. 修正法律通過後日本個人資訊保護委員會的後續工作（日本個人資訊保護委員會事務局，2026年7月31日）。2026年7月10日通過、7月17日公布依該資料。日文 ↩

12. AWS Regions（AWS Global Infrastructure documentation）。ap-northeast-1（東京）有4個可用區域，ap-northeast-3（大阪）有3個（2026年9月29日確認） ↩

13. 個人資料保護法指引問答集 Q10-25（日本個人資訊保護委員會，2021年9月新增）。日文，引文為筆者譯 ↩

14. 同問答集 Q12-3（日本個人資訊保護委員會，2021年9月更新）。日文 ↩

15. Route model inference requests across AWS Regions with cross-Region inference（Amazon Bedrock User Guide）。地理範圍設定檔與全球設定檔的差異、全球設定檔約便宜10%依該頁（2026年9月29日確認） ↩

16. Amazon Bedrock FAQs（AWS）。輸入與輸出不用於模型訓練，依該頁資安相關項目（2026年9月29日確認） ↩

17. Shared Responsibility Model（AWS） ↩

18. ISMS使用者指南 JIS Q 27001:2023（ISO/IEC 27001:2022）版 JIP-ISMS111-4.0（日本情報經濟社會推進協會JIPDEC，2025年3月31日）。新增的11項控制措施依第74頁表A-2。日文 ↩

19. Neil Perry, Megha Srivastava, Deepak Kumar, Dan Boneh, "Do Users Write More Insecure Code with AI Assistants?"（arXiv:2211.03622，ACM CCS 2023） ↩