> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 進階 XBOX 服務沙箱

> 深入探討作為生產環境中隔離虛擬環境的 XBOX Live 沙箱，包括內容隔離、授權範圍和開發工作流程。

另請參閱 [XBOX 服務沙箱概觀](/zh-TW/services/xbox-services/fundamentals/sandboxes/live-setup-sandbox)。

XBOX Live *沙箱*為開發提供整個私人環境。
本文說明什麼是沙箱、為何存在沙箱、沙箱如何適用於發行者，以及沙箱如何影響內部 XBOX 小組。
本文的對象是建置 XBOX One (或更新版本) 內容並使用沙箱的發行者。

XBOX Live 開發為發行者提供絕佳的機會，讓他們能夠使用生產品質的服務和生產 MSA 開發人員帳戶在生產環境中進行測試。
功能和彈性的增加需要在 Partner Center 中進行設定步驟，以建立遊戲資料並管理遊戲在開發期間和正式推出時的存取權。

沙箱是在生產環境中分割資料的一種方式。
由於所有內容只有單一生產環境，因此沙箱就像「虛擬環境」，在其中一個環境中產生的資料不會跨越到另一個環境。

## 在 XBOX Live 上隔離內容

在 XBOX Live 中，只有單一生產環境，所有預先發行 (開發中和 Beta)、認證和零售內容都位於其中。

內容隔離是確保生產環境中不會發生發行者內容外洩的方式。
就本質而言，內容隔離可確保任何要求存取資源 (遊戲或服務) 之權限的主體使用者、裝置或遊戲，都已獲授權存取該資源。
透過內容隔離，分割區會劃分為儲存遊戲或服務資料的沙箱；授權原則是在沙箱的範圍內定義的。

沙箱是分割生產環境中資料的一種方式。

* 使用 XBOX 360 時代的服務時，PartnerNet 和 ProductionNet 是兩個不同的環境。

* 使用 XBOX One (或更新版本) 服務時，單一生產環境包含 *n* 個不同的虛擬環境，其中每個虛擬環境都稱為*沙箱*。

由於所有內容只有單一生產環境，因此沙箱實際上是唯一的虛擬環境，在其中一個環境中產生的資料無法跨越到另一個環境。

下圖顯示單一生產環境，發行者可以在其中建立其私人開發沙箱。
只有獲授權的開發帳戶或開發套件才能存取這些沙箱。

圖 1. 生產環境中的沙箱。

<img src="https://mintcdn.com/microsoft-4404708b/ktEik-YaZoen6Rhy/images/gdk/services/sandboxes_image1.png?fit=max&auto=format&n=ktEik-YaZoen6Rhy&q=85&s=07d9acac4196853457cec428d08b8fdc" alt="沙箱結構和存取圖表" width="901" height="675" data-path="images/gdk/services/sandboxes_image1.png" />

就像 PublisherA 有開發沙箱一樣，其他發行者也有自己的開發沙箱。
相同的遊戲識別碼可能位於不同的沙箱中，但為該遊戲識別碼產生的資料在各沙箱之間是不同的。

有兩個只能由 Microsoft 填入的系統沙箱：CERT 和 RETAIL。
顧名思義，CERT 沙箱適用於發行前正在進行認證的遊戲，而 RETAIL 沙箱則是代表真實金錢交易、所有零售使用者和裝置都能存取的沙箱。

以前遊戲識別碼在 XBOX Live 中是唯一的，現在則是遊戲識別碼加上沙箱識別碼才是唯一的。
這同樣適用於產品識別碼和其他曾被視為唯一的識別碼空間。
它們現在必須與沙箱識別碼配對。
XBOX Live 中的所有資料在整個系統中都主要以沙箱識別碼進行分割。

## 遊戲的初始設定

遊戲誕生於 Partner Center。
遊戲會被指派遊戲識別碼、產品識別碼和服務設定識別碼 (SCID)。

遊戲或產品本身對 XBOX Live 而言沒有任何意義。
為了支援單一遊戲同時進行零售和開發使用，Partner Center 支援遊戲的*執行個體化*，以建立和維護必要的區別。
遊戲的執行個體位於沙箱中，這就是沙箱發揮作用的地方。

為了在 Partner Center 中建立遊戲，發行者會建立產品群組、指定產品群組的類型，然後在其中建立個別產品。

圖 2. 產品群組、產品、產品執行個體和沙箱之間的關係。

<img src="https://mintcdn.com/microsoft-4404708b/ktEik-YaZoen6Rhy/images/gdk/services/sandboxes_image2.png?fit=max&auto=format&n=ktEik-YaZoen6Rhy&q=85&s=0282e993686cc5ced3a5a60cb45196c4" alt="產品群組和產品執行個體圖表" width="1271" height="980" data-path="images/gdk/services/sandboxes_image2.png" />

## 產品執行個體

*產品執行個體*是遊戲、產品和設定資料在特定沙箱中的投影。
此資料在下列三個領域中描述：服務設定、目錄中繼資料和二進位檔。

### 服務設定

服務設定定義 (事件、統計資料、成就等)。服務設定是在產品執行個體層級定義的。

### 目錄中繼資料

位於目錄中的中繼資料，包括銷售文字、美術資產、供應情況/優惠資訊、授權資料等。

### 二進位檔

二進位檔可以用下列兩種方式之一表示：

1. 僅限中繼資料，以啟用側載。這包括內容識別碼、版本資訊和授權資訊。

2. 傳播至 CDN 且可下載至用戶端的完整二進位檔。

## 取得正確的存取權

在 XBOX One (或更新版本) 中，您的內容有兩種不同類型的存取權：

*設計階段存取*：透過 Partner Center 從 PC 存取 - 允許處理您產品的人員上傳、組織和處理內容、設定和中繼資料，但不允許他們執行或遊玩您產品的執行個體。

*執行階段存取*：從 XBOX 主機存取 - 允許您的開發人員、測試人員、審查人員以及最終您的客戶執行和遊玩產品執行個體。

<Note>
  為了可供執行階段存取，產品執行個體必須放置在沙箱中。組建放置在沙箱中之後，已獲授與該沙箱存取權的 Partner Center 使用者或開發套件裝置就可以執行該執行個體。為此，他們會透過 XBOX 主機，使用其中一個開發帳戶 (作為執行階段存取之虛擬使用者的特殊帳戶) 登入 Partner Center。
</Note>

當我們談論沙箱時，通常是在談論對 XBOX Live 上執行之內容的執行階段存取。
若要存取 XBOX Live 中的服務，需要遊戲識別碼。
一旦 [MicrosoftGame.config](/zh-TW/build/core-features/common/game-config/MicrosoftGameConfig-Overview) 包含遊戲識別碼，主機就會將遊戲識別碼傳送至 XBOX Live。
除非主體 (裝置或使用者) 已獲授與遊戲的存取權，否則 XBOX Live 安全性服務不會傳回有效的權杖。

此驗證程序是內容隔離的關鍵。
從非常高的層級來看：

* 主體群組可以包含 XBOX 使用者識別碼 (XUID)、裝置識別碼、遊戲識別碼或服務識別碼。

* 沙箱可以包含遊戲識別碼、產品識別碼或服務設定識別碼 (SCID)。

* 主體群組會獲授與沙箱的存取權。

因此，若要讓使用者或裝置存取沙箱中的預先發行遊戲，必須先透過 Partner Center 授與存取權。

圖 3. 透過 Partner Center 設定存取權的模型

<img src="https://mintcdn.com/microsoft-4404708b/ktEik-YaZoen6Rhy/images/gdk/services/sandboxes_image3.png?fit=max&auto=format&n=ktEik-YaZoen6Rhy&q=85&s=a356535fd8b8b2ab1d998309bb63a533" alt="沙箱資源存取圖表" width="1094" height="624" data-path="images/gdk/services/sandboxes_image3.png" />

內容隔離的有效性取決於您的組織擁有下列程序：

* 建立您的 Partner Center 使用者帳戶、每位使用者將用來登入以進行執行階段存取的開發帳戶，以及授與每位使用者成員資格的使用者群組。

* 建立受信任主機的裝置群組。

* 為您的每個開發沙箱精確指定哪些使用者群組和裝置群組可以存取其中的產品執行個體。

下圖說明此設定的範例。

圖 4. 未獲授權使用者的認證無法取得沙箱的存取權，獲授權之 Partner Center 使用者帳戶的一般認證也無法取得。
只有獲授權之 Partner Center 使用者帳戶所擁有之開發帳戶的認證，才能成功取得沙箱及其中目前所有產品執行個體的執行階段存取權。

<img src="https://mintcdn.com/microsoft-4404708b/ktEik-YaZoen6Rhy/images/gdk/services/sandboxes_image4.png?fit=max&auto=format&n=ktEik-YaZoen6Rhy&q=85&s=64339e23896884e2944f5ea5f0339b3d" alt="沙箱存取範例圖表" width="881" height="509" data-path="images/gdk/services/sandboxes_image4.png" />

### 開發帳戶設定

XBOX One (或更新版本) 中的開發帳戶只是套用了特殊規則的標準 Microsoft 帳戶 (MSA)。
開發帳戶在 XBOX Live 中用於開發。

開發帳戶：

* 必須在 Partner Center 中建立。

* 由發行者建立時，會被指派外部開發人員角色。

* 與建立開發帳戶的 Partner Center 帳戶相關聯。

* 只能登入開發套件。開發帳戶在零售裝置上會被拒絕登入。

* 可以免費購買 XBOX Live Developer Gold 訂閱或其他訂閱以進行測試。

### 使用者群組設定

使用者群組是第一種主體群組，是 Partner Center 使用者的集合。
當 Partner Center 使用者新增至使用者群組時，他們的開發帳戶會隨著這些 Partner Center 使用者一起流動。

因此，當使用者群組被指派給沙箱時，與該使用者群組中之 Partner Center 使用者相關聯的開發帳戶會新增至適當的主體群組，而主體群組會取得以支援該沙箱之主要資源集設定的原則。

<Note>
  為存取沙箱而建立的使用者群組，與用來防止存取 Partner Center 中產品群組和產品之設定資料的使用者群組相同。
</Note>

### 裝置設定

裝置也會新增至主體群組。
只有在透過 Game Developer Store 購買權利且裝置已佈建為開發套件時，裝置才能用作開發套件。

裝置佈建為開發套件之後，該裝置就會出現在可新增至裝置群組的裝置清單中。

### 裝置群組設定

裝置群組是第二種主體群組，也可以獲授與沙箱的存取權。
其設定與上述使用者群組設定類似。

## 沙箱

### 什麼是沙箱？

簡單來說，*沙箱是在生產環境中分割資料的一種方式*。

### 為什麼我們需要沙箱？

就像使用者和裝置存取遊戲一樣，遊戲也會存取服務。
我們引進了「遊戲群組」的概念，讓一組遊戲獲授與服務資源的存取權。

XBOX One (或更新版本) 的所有內容 (包括預先發行和零售) 只有單一生產環境。
因此，必須防止遊戲的多個執行個體 (預先發行/零售) 在相同的資源執行個體上運作。

### 沙箱中有什麼？

沙箱包含新增至沙箱之每個遊戲的產品執行個體。

### 什麼是沙箱識別碼？

沙箱識別碼是遊戲、產品或服務設定之資料的分割單位。
多個遊戲可以存在於同一個沙箱中，這是它們共用任何服務設定資料的先決條件。

沙箱識別碼 (區分大小寫) 是下列格式的字串：\<PublisherMoniker>.*n*。

以下說明範例沙箱識別碼 XLDP.5：

* *發行者代稱*在所有發行者之間是唯一的。因此，"XLDP" 是此特定發行者的發行者代稱。發行者代稱是在開發人員客戶經理於 Partner Center 中「啟用」發行者時建立的。

* 數字 *"n"* 識別沙箱的編號。在此案例中，"5" 是為此發行者建立的第六個沙箱。

當遊戲資料在服務之間移動時，XBOX 服務會使用沙箱識別碼來唯一識別所產生之資料的「環境」。

### 哪些資料會沙箱化？

下圖顯示哪些使用者和遊戲資料會沙箱化。

<img src="https://mintcdn.com/microsoft-4404708b/ktEik-YaZoen6Rhy/images/gdk/services/sandboxes_image5.png?fit=max&auto=format&n=ktEik-YaZoen6Rhy&q=85&s=db6d1128adfd4e737c408916e1b47a49" alt="哪些資料會和不會沙箱化的分類圖表" width="1344" height="774" data-path="images/gdk/services/sandboxes_image5.png" />

### 全域覆寫沙箱

開發人員會在開發套件上設定沙箱識別碼，從而設定開發套件執行所在的沙箱；這也稱為全域覆寫沙箱。
因此，從開發套件中的遊戲 (殼層應用程式和一般應用程式) 向 XBOX Live 服務 (例如成就、配對、授權、EDS 等) 提出的所有要求，都會在該沙箱中進行。

全域覆寫沙箱也意味著瀏覽時只能看到在全域覆寫沙箱中擷取的內容。

## 沙箱的類型

沙箱有兩種不同的類別。
這些類別的定義如下：

* *發行者沙箱*。發行者可以存取其開發中的沙箱。這些沙箱可能看起來像 XLDP.0、XLDP.1、XLDP.2、XLDP.3 等。這是發行者放置其遊戲產品執行個體的地方。這些沙箱的存取權僅限於發行者授與存取權的使用者/裝置

* *Microsoft 沙箱*。這些是內建的沙箱：RETAIL 和 CERT。只有 Microsoft 可以發佈至這些受保護的沙箱。

### CERT 沙箱

當遊戲準備好正式推出時，必須先通過認證。
CERT 沙箱是由 Microsoft 控制的沙箱，只有認證人員才能存取。
發行者可以看到他們擁有的哪些內容正在進行認證。

在認證期間失敗的任何產品執行個體，都可以由發行者使用 Partner Center 帶回開發沙箱以進行偵錯和修正。

### RETAIL 沙箱

RETAIL 沙箱是為 XBOX One (或更新版本) 建立之所有內容的最終目的地。

遊戲通過認證之後，就會新增至 RETAIL 沙箱。
只有綠色簽署的內容才能在 RETAIL 沙箱中執行。
這有一個重要的含意，就是發行者主導的 Beta 版也是在 RETAIL 沙箱中進行。
在 RETAIL 沙箱中產生的資料代表真實的客戶生產資料。

RETAIL 沙箱中內容的存取權仍可透過內容隔離進行控制。
例如，發行者主導的 Beta 版在 RETAIL 沙箱中執行，由發行者選擇哪些主體群組可以存取發行者定義的 Beta 資源集遊戲。
Beta 遊戲產生的服務資料是真實的生產資料，並在遊戲正式推出後繼續存在。

### 跨沙箱資料互動

根據定義，沙箱是限制資料共用的容器。
因此，不可能進行跨沙箱資料互動。

## 組織您的沙箱

本節提供發行者如何組織沙箱的範例。
發行者需要了解如何使用沙箱來組織資料。

下列範例只顯示透過內容隔離進行的執行階段存取管理。

### 案例 1：兩個遊戲，一個沙箱

發行者的基本結構可能是：

* 兩個遊戲，發行者擁有的所有使用者和裝置在設計階段和執行階段都可以存取。

* 每個遊戲一個產品執行個體。

在此情況下，發行者只需要單一沙箱來存放所有預先發行內容。

下圖顯示使用者群組。
如果認為較容易，發行者可以選擇使用裝置群組而非使用者群組。
此外，此使用者群組具有沙箱 XLDP.1 及此沙箱中遊戲的執行階段和設計階段存取權。

<img src="https://mintcdn.com/microsoft-4404708b/ktEik-YaZoen6Rhy/images/gdk/services/sandboxes_image6.png?fit=max&auto=format&n=ktEik-YaZoen6Rhy&q=85&s=47684bcf5795ebb23df654cbe0969626" alt="包含兩個遊戲的使用者群組流程圖" width="501" height="531" data-path="images/gdk/services/sandboxes_image6.png" />

### 案例 2：一個遊戲，不同的小組

在此模型中，需求如下：

* 一個遊戲。

* 開發小組處理每日組建。

* QA 小組處理每週的 LKG。

* 開發小組需要在發生錯誤時對每週 LKG 進行偵錯。

* 財務小組需要存取與遊戲目錄發行相關的價格卡和其他中繼資料。

下圖顯示 TitleX 有兩個產品執行個體：PI-1 和 PI-2。
產品執行個體必須位於沙箱中，而同一遊戲的兩個產品執行個體不能位於同一個沙箱中。
因此，TitleX-PI-1 位於沙箱 XLDP.1，而 TitleX-PI-2 位於沙箱 XLDP.2。

開發使用者群組可以存取這兩個沙箱，而 QA 使用者群組只能存取沙箱 XLDP.2。

此外，財務使用者 (群組 C) 具有 TitleX 的設計階段存取權。
由於財務使用者群組通常不會對遊戲進行任何執行階段偵錯，因此將他們分開。

<Note>
  無論組織方式為何，Partner Center 使用者都可以屬於多個使用者群組。
</Note>

<img src="https://mintcdn.com/microsoft-4404708b/ktEik-YaZoen6Rhy/images/gdk/services/sandboxes_image7.png?fit=max&auto=format&n=ktEik-YaZoen6Rhy&q=85&s=e38588175024de7d67386092d0d73309" alt="一個遊戲搭配多個使用者群組的流程圖" width="625" height="548" data-path="images/gdk/services/sandboxes_image7.png" />

### 案例 3：兩個遊戲，完全分開

在此範例中，需求略有變化：

* 兩個遊戲。

* 每個遊戲的存取權應限制為特定的一組人員。

* 每個遊戲一個產品執行個體。

* 一個需要存取遊戲之設計階段 Partner Center 設定資料的管理員使用者群組。此群組中的人員都是發行者的管理員，可以控制發佈至目錄的所有資料 (目錄中繼資料、財務、行銷、認證提交等)

在此模型中，發行者選擇讓兩個遊戲完全分開，因此將這兩個遊戲指派到兩個不同的沙箱中。
發行者也選擇建立個別的管理員使用者群組，並指派這兩個產品的存取權。

<img src="https://mintcdn.com/microsoft-4404708b/ktEik-YaZoen6Rhy/images/gdk/services/sandboxes_image8.png?fit=max&auto=format&n=ktEik-YaZoen6Rhy&q=85&s=2a456b7a9eebf65a6b3d86a66f7b9963" alt="一個管理員、兩個使用者群組和兩個遊戲的流程圖" width="625" height="548" data-path="images/gdk/services/sandboxes_image8.png" />

### 案例 4：隨您喜好

由於連線數量眾多，為了讓說明簡短，我們選擇只顯示沙箱執行階段連線。
您也可以新增其他設計階段存取權限。

在此範例中，需求如下：

* 只有特定人員可以存取其發行者內的特定遊戲。

* 發行者與來自不同公司的廠商合作，而這些廠商可能是短期的。

* 發行者應該能夠停用遊戲，並藉此防止存取廠商或全職員工曾有權存取的任何資料。

為了對此需求進行建模，可以採用如下所示的結構。

下列採用的模型為：

* TitleX 和 TitleY 在沙箱 XLDP.1 中各只有一個產品執行個體。

* TitleZ 有兩個產品執行個體，一個在沙箱 XLDP.2，另一個在沙箱 XLDP.3。

* 全職員工使用者群組 B 獲授與所有沙箱中產品執行個體的存取權。

* 廠商使用者群組 A 是僅限廠商的使用者群組，獲授與沙箱 XLDP.1 的存取權。

* 廠商裝置群組 C 是僅限廠商的使用者群組，獲授與沙箱 XLDP.3 的存取權。

<img src="https://mintcdn.com/microsoft-4404708b/ktEik-YaZoen6Rhy/images/gdk/services/sandboxes_image9.png?fit=max&auto=format&n=ktEik-YaZoen6Rhy&q=85&s=9acf65d3a02f1ea7c7e497103ab06e5f" alt="自訂使用者群組和遊戲存取權的流程圖" width="625" height="443" data-path="images/gdk/services/sandboxes_image9.png" />

## 判斷您的裝置所指向的沙箱

XBOX 服務 API 包含應用程式設定單一執行個體，可讓您在執行階段查看遊戲所指向的沙箱。如果使用 GDK，可以透過 [XSystemGetXboxLiveSandboxId](/zh-TW/reference/system/xsystem/functions/xsystemgetxboxlivesandboxid) 完成此動作。


## Related topics

- [沙箱](/zh-TW/services/xbox-services/fundamentals/sandboxes/index.md)
- [XBOX 服務沙箱概觀](/zh-TW/services/xbox-services/fundamentals/sandboxes/live-setup-sandbox.md)
- [針對登入和沙箱錯誤進行疑難排解](/zh-TW/services/xbox-services/develop/troubleshooting/live-troubleshoot-sandboxes.md)
- [PC 沙箱切換器 (XblPCSandbox.exe)](/zh-TW/tools/tools-services/live-pc-sandbox-switcher.md)
- [XBOX 服務設定的摘要頁面](/zh-TW/services/xbox-services/fundamentals/portal-config/live-portal-summary-tab.md)